Tim Gardner tim.gardner at
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 (,  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
> functionality.
> 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

More information about the ubuntu-server mailing list