[Ksummit-2012-discuss] [ATTEND] Distribution kernel relationship to -stable, test automation and frameworks

Mel Gorman mgorman at suse.de
Fri Jun 29 11:29:56 UTC 2012

I'm also on the program committee but eventually that hat will fall off
so I will say why I want to attend. My expertise is primarily memory
management and much of the last year has been divided between mainline and
distribution kernel work. I've spent a decent portion of time identifying
regressions since 2.6.32 and as a result of handling bugs that superficially
looked like MM problems I've also managed to stray into other areas such
as scheduler and IO layers. Obviously I'm very interested in any discussion
in these areas whether they take place as part of a topic or in the hallway.

I'm very interested in discussing the relationship between distribution
kernels and -stable. I think -stable is a big bonus in narrowing down
the number of patches that need to be picked up by distributions but I
do not think that -stable gets enough back from the distribution kernel
work.  This leads to some duplicated effort between distributions that is
inconvenient when trying to decide if other distributions have experienced
a particular bug. I'm interested in seeing can we agree on what sort of
patches should be pushed from distribution kernels back into -stable.

I'm keen on the various proposals around testing, regression tracking and
testing frameworks. I think Rafael does a great job on tracking functional
regressions but in general I think we do a worse job on tracking performance
regressions. They tend not to get caught until an enterprise distribution
does a major release and pulls in more QA departments. I know there are QA
departments in different companies currently doing great work but we do
not always see the results until very late. Sometimes the configurations
are extreme cases and are not necessarily reproducible if the test code
is internal. While I think improvements in scalability are important I
think we should also have a very solid handle on the basic performance
metrics first. I have my own testing framework and I'm posting up some of
the results from it at the moment. While there are warts and space for
significant improvement, it does the basic job reasonably well without
complex dependencies. I'd rather avoid the situation where we start a
testing framework from scratch again when there are so many existing
frameworks out there. Test frameworks might be one of those things that
no matter what you do to it, it ends up looking a bit ugly.

There are also some indications that will be some decisions to be made around
where we draw the line on what the kernel does automatically and what it
defers to userspace.  Power-aware scheduling was something the kernel tried
to do automatically but did not necessarily work out first time around.
AutoNUMA is a recent topic that highlights the issue of what the kernel
should be doing automatically and what should it be providing interfaces
to userspace for. I expect it will come down to being a case-by-case basis
but discussing a few examples will help identify where this fuzzy line is
and I'd like to be part of such a discussion.

Mel Gorman

More information about the Ksummit-2012-discuss mailing list