Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats

[Shailabh Nagar]

Jay Lan wrote:

> Shailabh Nagar wrote:
>  
>
> > Andrew Morton wrote:
> >
> >    
> >
> > > On Wed, 21 Jun 2006 12:11:13 -0700
> > > Jay Lan <jlan@xxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/