On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote:Didn't quite understand...could you please elaborate ?
Andrew Morton wrote:[..]
Shailabh Nagar <nagar@xxxxxxxxxxxxxx> wrote:
So if we can detect the silly sustained-high-exit-rate scenario then itThe "buffering within taskstats" might be a way out then.
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.
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 thoseSounds good.
parameters settable because different machines or users may have
different view as to what is proper - maybe even as simple as sysctl.
Yes it does. Thanks for the tips.
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