Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2014-05-08 at 11:24 -0500, Christoph Lameter wrote:
> On Fri, 2 May 2014, Josh Triplett wrote:
> 
> > - An overview of why the kernel's size still matters today ("but don't
> >   we all have tons of memory and storage?")
> 
> Kernel size matters quite a bit for performance. Processor caches are key
> to performance and therefore the cache footprint of a function determines
> the the possible performance. The smaller the functions and the less data
> they access the faster they will run.

This is about footprint, though, it's about optimizing a code path to
run in the fewest instructions possible, right?      

> Therefore it needs to be possible to reduce the size of the kernel by
> disabling unwanted functionality (f.e. cgroups). In order for that to
> happen features need to be as independent as possible and also the user
> space tools (like systemd) need to be able to handle a kernel with reduced
> functionality.

I don't believe that follows.  As long as the added code doesn't cause
the cache footprint of the working set to expand, there's no performance
reason to compile it out.   If you choose not to use syscalls, then the
paths are inert from a performance point of view and it doesn't matter
if they are config'd in or out.  Cgroups, on the other hand impacts
performance because it adds to the execution path of several syscalls.
We were careful to use static branching to minimise this, but obviously
it does expand the cache footprint.  Do you have any figures for the
performance issues it's causing (being compiled in but unused)?  If it's
significant, we could try static branching to out of line areas which
shouldn't impact the cache footprint.

James