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 [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]
