From: Jay L. <jl...@en...> - 2006-04-10 17:15:51
|
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 |