Re: [PATCH] new CSA patchset for 2.6.8

[Jay Lan <jlan@engr.sgi.com>]

I do like to see a common data collection method in the kernl. Kernel
does not need to decide how the data to be presented to the
user space. An accounting loadable module such as CSA or ELSA will
take care of how the data to be presented to meet the needs of
different users.

Sounds reasonable?

Regards,
  - jay


Tim Schmielau wrote:
> On Thu, 26 Aug 2004, Arthur Corliss wrote:
> 
> 
>>I would be very interested in a CSA implementation similar to what I have on
>>IRIX.  I will also plead guilty to not having downloaded the updated patches
>>for either the kernel or the tools.  I'm continuing to use my poor hack until
>>a permanent solution gets accepted into the kernel, at which point I'll
>>adopt that.
> 
> 
> That's ok, we carefully discussed the changes to make sure no new tools
> are required ;-)
> 
> 
>>And if it counters the impression at all, I'm not a kernel developer, I
>>proposed my hack out of need as a user of the tools.  I also try to stay away
>>from modified kernels, so I'm running Marcelos' 2.4 stable branch with only
>>the 32bit u/gid_t hack applied.  That's why I haven't had any feedback on the
>>-mm branch.
> 
> 
> I haven't even tried to get a patch into 2.4, since Marcelo is (rightly)
> quite resilent to new features.
> 
>>In short, for my use BSD accounting is sufficient, but I'd love to see CSA in
>>Linux as well.  Linux hasn't moved too far into roles where it's a necessity
>>(for what I'm doing, anyway), but I see CSA as something that would certainly
>>help it assume those roles.
> 
> 
> Does this mean you would want to have both in the same kernel, potentially
> turning on both at the same time?
> 
> 
> Ok, let me summarize what I learned until now:
> 
> It should be easy to combine the data collection enhancements from
> CSA and ELSA to provide a common superset of information.
> 
> Output file formats vary, but might be unified if projects don't insist
> too much.
> Main difference between CSA and ELSA on the one hand and BSD acct on the
> other is that the latter writes one record per process, while the former
> write one per job.
> With the new BSD acct v3 format, it should be possible to do per job
> accounting entirely from userspace, using pid and ppid information to
> reconstruct the process tree and some userland database for the
> pid -> job mapping. It would, however, be greatly simplified if the
> accounting records provided some kind of job id, and some indicator
> whether or not this process was the last of a job (group).
> 
> CSA and ELSA might even be more lightweight since fewer accounting records
> are actually written.
> 
> Sounds like it should be possible to fulfill the different needs by
> having loadable modules for the different output formats, or by a /proc
> entry that controls some aspects like whether records are written per
> job or per process.
> 
> Comments?