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

[jamal <hadi@cyberus.ca>]

On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote:
> Andrew Morton wrote:
> 
> >Shailabh Nagar <nagar@watson.ibm.com> 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.

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

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

cheers,
jamal
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/