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

[Jay Lan <jlan@engr.sgi.com>]

I made two feedback on 3/31 only to see them bounced
back over the weekend. :(

Here was my first feedback:

Shailabh Nagar wrote:
 >>
 >>Following Andrew's suggestion, here's my quick overview
 >>of the various other accounting packages that have been
 >>proposed on lse-tech with a focus on whether they can
 >>utilize the netlink-based taskstats interface being proposed
 >>by the delay accounting patches.
 >>
 >>Please note that unification of statistics *collection* is not
 >>being discussed since that kind of merger can be done as these
 >>patches get accepted, if at all, into the kernel. To try and
 >>unify right away would hold every patch (esp. delay accounting !)
 >>hostage to the problems in every other patch unnecessarily. As
 >>long as the interface can be unified, the merger of the
 >>collection bits can always happen without affecting user space.
 >>
 >>Stakeholders of each of these patches, on cc, are requested to
 >>please correct any misunderstandings of what their patches do.
 >
 >To me, data collection and formation before sending down to
 >userspace is very important part.  What this taskstats netlink
 >interface does is  just to provide an interface to send "already
 >formatted" data to userspace. In other words, it will replace
 >"writing accounting records to an accounting file" step currently
 >performed in BSD accouting and in CSA. If i understand it correctly,
 >you have delayacct.c sitting on top of taskstats interface, and
 >all other accounting methods should build their own layer on top
 >of taskstats as well. For example, potentially BSD acct.c can replace
 >fput() (and other statements dealing with acctounting file) with
 >this interface. Same for CSA.
 >
 >This approach sounds right to me. Actually i am very glad that you
 >made effort to provide a common ground here. Yet, this is only
 >one step. I will apply your patchset on top of 2.6.16-mm to see
 >what i get and give more feedback later.

And, here is the second one:

> 
> 
> This taskstats thing is much more complicated than what Guillaume
> used to have when he put up a prototype of doing ELSA over netlink.
> One confusing point is the struct taskstats. If it is to be used
> as the big data struct to contain all accounting data everybody
> needs (as Shailabh suggested on his CSA analysis section), then
> if at do_exit() every accounting methods are to be invoked to
> handle their netlink transmission (as currently implemented in
> delayed accounting), would it be a lot of overhead sending "grand
> data" too many times? Maybe each layer should just format data of
> their interest when invoked from do_exit, and then we do one call
> to genetlink to deliver formated struct taskstats data?
> 
> Also, as you pointed out, CSA only retrieve data at end of task
> but delayed accounting needs to retrieve data during the process.
> So, i think we need more than one record types, not just the
> struct taskstats, so that the user space delayed accounting 
> application can specify to get only delayed accounting record.
> 
> Honestly, this taskstats.c layer looks more like something
> extracted from delayed accounting than a carefully designed 
> common ground to me. Patch 8/8 is about documentation of delayed
> accounting than the common ground for various accounting methods.
> Can you please present us a documentation of design concept of
> such a common layer? That would help me. I guess i also need to 
> catch up on genetlink to better understand taskstats code.
> 
> Regards.
>  - jay
> 

Regards,
  - jay