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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



jamal wrote:

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.
Didn't quite understand...could you please elaborate ?
Today we have a slab cache from which the taskstats structure gets allocated at the beginning
of the exit() path.
The upper limit to which you refer is the amount of slab memory the user is willing to be used
to store the bursty traffic ?


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

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.
Yes it does. Thanks for the tips.

Will code up something and send out so this can become more concrete.

--Shailabh

cheers,
jamal



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux