On Thu, 2006-29-06 at 21:11 -0400, Shailabh Nagar wrote: > Andrew Morton wrote: > > >Shailabh Nagar <[EMAIL PROTECTED]> 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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
