Messages in this thread | | | Subject | Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats | From | jamal <> | Date | Thu, 29 Jun 2006 21:30:47 -0400 |
| |
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/
| |