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

jamal
2006-06-30T01:30:57Z

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