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

[Shailabh Nagar <nagar@watson.ibm.com>]

Peter Chubb wrote:

> > > > > > "Shailabh" == Shailabh Nagar <nagar@watson.ibm.com> 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 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/