lkml.org 
[lkml]   [2006]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Patch 0/8] per-task delay accounting
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

-
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/

\
 
 \ /
  Last update: 2006-04-10 19:18    [W:0.119 / U:1.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site