Re: [Patch 0/8] per-task delay accounting

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

 



Peter Chubb wrote:

"Shailabh" == Shailabh Nagar <[email protected]> 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 syscalls. Neither of the latter two can return data after a task has exited (atleast not easily...you 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 ?

--Shailabh







-
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