From: Shailabh N. <na...@wa...> - 2005-09-22 17:41:26
|
Jay Lan wrote: >> >> On 23 Feb 2005 Guillaume said, on this mailing list: >> >> Guillaume Thouvenin <gui...@bu...> wrote: >> >>> On Wed, 2005-02-23 at 00:51 -0800, Andrew Morton wrote: >>> >>>> ... >>>> The 2.6.8.1 ELSA patch adds quite a bit of kernel code, but from what >>>> you're saying it seems like most of that has become redundant, and all >>>> you now need is the fork notifier. Is that correct? >>> >>> >>> Yes, that's correct. All I need is the fork connector patch. It needs >>> more work like, as you said, sending an on/off message down the netlink >>> socket. I'm working on this (thank you very much Andrew for your >>> comments). >> >> >> >> If this is still true for ELSA, what's different about your accounting >> requirements? > > > Andrew, ELSA does not collect system accounting raw data. It relies on > BSD and CSA to provide accouting data via a pacct file in binary format. > That is why ELSA does not need an exit notifier. > > ELSA allows users to view accounting data in terms of "job" (a group of > processes). It relies on fork notifier to put pid's into one "job" > container if it was forked from the same ppid. Thus, ELSA performs > process grouping and data presentation functions. > > Per-process accounting data is accumulated at task and task->mm. These > data need to be saved off somewhere before a task struct is freed. > The action is triggered by an exit event. The BSD accounting has > a function hook at do_exit() to do just that. > > What you like to see is to move fork/exit/exec event notification > to userspace through a connector. However, a connector is a > unreliable datagram socket. If we lose exit notification when system > is extremely busy, we lose accounting data once task struct is freed. > That is not what we have today. Today we have BSD function hook > in the kernel to copy off the data. > > "pnotify" is not an accounting thing. It is viewed as an in-kernel > event notification. Functionality-wise it is like a connector > except that "pnotify" does event notification in the kernel while > connector sends event notification to userspace. > > A fork notifier is used to do process grouping. An exit notifier > is used to save off accounting data. > > System accounting needs a reliable event notifier. It is especially > true on exit events. > > 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. 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). 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. -- 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 > |