tim.gardner at canonical.com
Wed Jun 30 20:10:38 UTC 2010
On 06/30/2010 12:55 PM, John Johansen wrote:
> The server team has requested that the kernel team evaluate the inclusion
> of atop into the kernel as it allows for better task accounting.
> The kernel patches apply cleanly and have been built and have been lightly
> tested on the Maverick kernel. With some discussion of the patches at
> The remaining question is whether the atop patches should be included.
> There are a few concerns:
> PATCH 2 modifies the process-accounting record, into a layout that is
> incompatible with BSD v3 accounting. I have looked around for what
> requires BSD v3 accounting and found a few accounting projects like gnus
> acct and elsa (http://elsa.sourceforge.net/), But several other projects
> like htop (requires /proc), iotop, latencytop do not seem to be using it
> (though I didn't dive into the code to verify that).
> It is possible to apply just the first patch and obtain some of the atop
> The other immediate concerns with the patches are: potential performance
> regressions (none noticed in light testing), and just the general
> hesitance to accept patches that are out of tree/not going upstream.
> At this time I am unsure of the atop's projects planning for upstreaming
> I have contacted them but at this time do not have a reply. With a
> quick search the last submission to LKML I can find is from 2008
You are correct in that I am reluctant to drag in unmaintained crack
into core kernel structures.
I still find 'better task accounting' to be insufficient justification.
What specifically makes for better task accounting? Why is atop better
then other methods? As far as I can tell the current patches still
suffer from the deficiencies mentioned by Andrew Morton in
Gimme an example of a problem that atop will help solve for which no
other method will suffice.
Tim Gardner tim.gardner at canonical.com
More information about the ubuntu-server