From: Chandra S. <sek...@us...> - 2005-09-22 18:11:31
|
On Thu, 2005-09-22 at 13:44 -0400, Shailabh Nagar wrote: > Jay Lan wrote: <snip> > > > > Does CKRM save off accounting data also? How is that done? > > Didn't quite understand the question but I guess this is a good time to > relist our requirements: > > CKRM needs to get two types of "accounting" data > > 1. events like fork, exit, exec, setuid, setgid etc. > In the new CKRM implementation (where classification is being done in > user space), we don't need a callback to be invoked from a kernel module > at these events - just the notification to userspace is sufficient > > Here we can piggyback onto any notification scheme and pnotify is more > heavyweight than what we need. and since we moved our functionality to user space, if we are going to use pnotify for this, then we have add some additional code to send that data to user space. So, connector is a preferred by CKRM in this context. > > Not losing any event is important to us but we don't expect this to be a > major design constraint. If a connector-based solution has buffering > problems in high-volume situations (which should be rare), a relayfs > based solution can also be explored. Our earlier design used relayfs > without any problems even with rapid event generation (however its not a > suitable design going forward since we also need to send commands from > userspace into the kernel which relayfs cannot do). This is what I referred yesterday (as moving to user space). > > 2. per-task accounting data on > - time spent by a task waiting for I/O to complete > - time spent waiting for page faults to be serviced (subset of I/O wait > time) > - time spent waiting for CPU (runnable but not running) > - possibly some additions of the same type > > For this kind of data, we're talking of the following type of kernel > changes > - marking the state of a task using task flags > - accumalating the data in fields added to the task_struct > - sending the accumalated data periodically and/or on demand, through a > kernel module, to userspace. A connector-based mechanism for sending > data should be adequate since this is definitely not a high-volume data > output situation. pnotify doesn't help us here at all afaics. > > > We'll need to go over the pnotify proposal in some more detail but I > think it will be very useful to follow up on Andrew's suggestion and get > some consensus between ELSA, CSA, CKRM (and other projects that I don't > know of) on the accounting requirements of the different projects. > > By and large, a connector-type notification scheme is what we're leaning > towards. There is a need for fork() and exit() notification in CKRM in kernel: - at fork() to initialize the task data structure - at exit() to relinquish the task from the class and send the uncollected accounting data of the task( (2) above) to the user space. I was thinking of using connector for this too, but pnotify would be simpler to use. But, pnotify is little heavy weight for our purposes. All we need is just a notification, with the task data structure. Is making pnotify leaner an option for PAGG ? something as simple as what is in the patch http://marc.theaimsgroup.com/?l=linux- kernel&m=111532025203086&w=2 Note that we do not need all the events listed there anymore, only fork and exit. chandra > > -- Shailabh > > > > > > > Thanks, > > - jay > > > > > >> > > > > > > > > ------------------------------------------------------- > > SF.Net email is sponsored by: > > Tame your development challenges with Apache's Geronimo App Server. > > Download > > it for free - -and be entered to win a 42" plasma tv or your very own > > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > > _______________________________________________ > > Lse-tech mailing list > > Lse...@li... > > https://lists.sourceforge.net/lists/listinfo/lse-tech > > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Lse-tech mailing list > Lse...@li... > https://lists.sourceforge.net/lists/listinfo/lse-tech > -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sek...@us... | .......you may get it. ---------------------------------------------------------------------- |