[lkml]   [2006]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Patch 0/8] per-task delay accounting
Peter Chubb wrote:

>>>>>>"Shailabh" == Shailabh Nagar <> writes:
>Shailabh> Peter Chubb wrote:
> (microstate accounting patch)
>>> It's still maintained in a sporadic sort of way --- I update it
>>>when either I need it for something, or someone's downloaded it and
>>>asks why it doesn't work agains kernel X.Y.Z. I see a few
>>>downloads a month.
>Shailabh> So do you intend to pursue acceptance ? If so, do you think
>Shailabh> the netlink-based taskstats interface provided by the delay
>Shailabh> accounting patches could be an acceptable substitute for the
>Shailabh> interfaces you had (from an old lkml post, they appear to be
>Shailabh> /proc/tgid/msa and a syscall based one) ?
>I'd have to take a close look.
Please do ! As I mentioned in the other note where I summarize the
various accounting packages
I think it should be fairly easy for microstate accounting to extend the
structure returned by the
taskstats interface.

> The syscall interface is modelled on
>getrusage(), and only lets you get your own or your children's data;
>I'm not too worried about trashing it, as it should be possible to
>emulate in terms of netlink (albeit at a cost; system calls are
>relatively cheap)
>/proc/<pid>/task/<tid>/msa lets you get at anything you own. I use
>awk scripts to process the msa file in /proc/... and pipe it into
>gnuplot at n second intervals; a netlink interface would need to have
>an auxiliary program to read it and then squirt it into the scripts, I
>think --- or is there a way to get ASCII out on demand?
No. The use of netlink pretty much means you have to use an auxiliary
program. We provide
one already (as part of the documentation to the patches).

What netlink buys you is the ability to
- get data for a task after it has exited (ie netlink serves as a buffer)
- get data for large number of tasks more efficiently than /proc

>I quite often
>use cat to do quick checks on whats going on too --- so overall I think
>the /proc interface is desirable.
Yes, /proc is more convenient both for cat'ting and also since its used
by tools like top.
Delay accounting patches also provide the "block I/O wait (including
swapin)" statistic through
/proc/tgid/stat for convenience and so that top etc. can use it while
displaying per-task stats.

However, the question here is this:

*if* a single, unified interface for per-task statistics was deemed to
be desirable (as Andrew is
effectively suggesting we explore), what would that interface be ?
/proc-based, netlink based or syscall-based ?

I would submit it is netlink-based since it is a superset of /proc and
Neither of the latter two can return data after a task has exited
(atleast not can always invent
infrastructure to buffer per-task stats but it would be cumbersome)
Whereas the former can, with the help of an auxiliary program, provide
the same data that /proc and syscalls can.
The price paid by /proc and syscall users for unification is
convenience, not loss of functionality.

Would you agree ?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-03-31 18:06    [W:0.073 / U:11.484 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site