Jay Lan wrote:
Shailabh Nagar wrote:
Andrew Morton wrote:
On Wed, 21 Jun 2006 12:11:13 -0700
Jay Lan <[email protected]> wrote:
Another observation that i considered bad news is that all
10 runs produced 1 to 5 recv() error with errno=105 (ENOBUF).
Well that's rather bad. AFAICT most of the allocations in there are
GFP_KERNEL, so why is this happening?
Need to trace the cause.
Because the kernel is producing netlink messages faster than
userspace can
consume them, perhaps?
Hmm...possible. A quick check would be to reduce the frequency of
exits and see.
If so, the sender needs to block, which means we
need to make reception of these stats a privileged operation?
Won't it suffice to make delivery of these stats best effort, with
userspace dealing with missing data,
How do you recover the missed data?
Not recover as such but just let userspace know data was dropped so it
can work around it.
rather than risk delaying exits ? The cases where exits are so
frequent as in this program should be
This is very true. However, it was a 2p IA64 machine. I am too frightened to
speak "512p"...
True, but then you should presumably have more receivers or some other
strategy to consume the output
faster ? Blocking is an even
worse idea if that many CPUs will be waiting around for stats data to be
written out....
--Shailabh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
