Re: [PATCH] new CSA patchset for 2.6.8

[Arthur Corliss]

On Thu, 26 Aug 2004, Tim Schmielau wrote:

> That's ok, we carefully discussed the changes to make sure no new tools
> are required ;-)

Understood, and appreciated.

> Does this mean you would want to have both in the same kernel, potentially
> turning on both at the same time?

I think that's definitely the route to go.  Not everyone needs the level of
visibility that CSA provides, so I think that with a unified data collection
methodology the users can decide for themselves what they need, and the kernel
stays in good shape with no implementation-specific bloat.

> 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.

I don't think we'd necessarly want a unified accounting *file*.  BSD account
files grow pretty damned quick as it is, and that's with a lot less visibility
than if you included the extract counters that CSA provides.  Make the data
available the logging module(s) or what have you via a common struct, but let
each module decide what to actually commit to disk, and when (on job exit,
etc.).

> 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.

On one hand, loadable modules would be more helpful for people doing
side-by-side comparisons of the accounting systems, but the /proc method would
be better for dynamic adjustments of a single system.  I don't think I have a
horse in this race, either way.

	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/