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

[Shailabh Nagar]

jamal wrote:

> On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote:
>  
>
> > Andrew Morton wrote:
> >
> >    
> >
> > > Shailabh Nagar <nagar@xxxxxxxxxxxxxx> wrote:
> > >      
> [..]
>  
>
> > > So if we can detect the silly sustained-high-exit-rate scenario then it
> > > seems to me quite legitimate to do some aggressive data reduction on that. 
> > > Like, a single message which says "20,000 sub-millisecond-runtime tasks
> > > exited in the past second" or something.
> > >
> > >
> > >      
> > The "buffering within taskstats" might be a way out then.
> >    
>
> Thats what it looks like.
>
>  
>
> > As long as the user is willing to pay the price in terms of memory,
> >    
>
> You may wanna draw a line to the upper limit - maybe even allocate slab
> space.
>  
Didn't quite understand...could you please elaborate ?
Today we have a slab cache from which the taskstats structure gets 
allocated at the beginning
of the exit() path.
The upper limit to which you refer is the amount of slab memory the user 
is willing to be used
to store the bursty traffic ?


> > we can collect the exiting task's taskstats data but not send it 
> > immediately (taskstats_cache would grow) 
> > unless a high water mark had been crossed. Otherwise a timer event would do the 
> > sends of accumalated  taskstats (not all at once but
> > iteratively if necessary).
> >
> >    
>
> Sounds reasonable. Thats what xfrm events do. 

> Try to have those
> parameters settable because different machines or users may have
> different view as to what is proper - maybe even as simple as sysctl.
>  
Sounds good.

>  
>
> > At task exit, despite doing a few rounds of sending of pending data, if 
> > netlink were still reporting errors
> > then it would be a sign of unsustainable rate and the pending queue 
> > could be dropped and a message like you suggest could be sent.
> >
> >    
>
> When you send inside the kernel - you will get an error if there's
> problems sending to the socket queue. So you may wanna use that info
> to release the kernel allocated entries or keep them for a little
> longer.
>
> Hopefully that helps.
>  
Yes it does. Thanks for the tips.

Will code up something and send out so this can become more concrete.

--Shailabh

> cheers,
> jamal
>
>
>  

-
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/