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

[Li Zefan <lizefan@huawei.com>]

On 2014/5/9 8:31, James Bottomley wrote:
> 
> 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.
> 

Mel has recently working on a patchset for mm optimization, and I
just noticed one particular patch adds static_key to eliminate cpuset
overhead in mm code path. We sure can use static_key more in cgroup.

New features tend to add new stuff to structures like task_struct, which
static_key or any other mechanisms can't help.