From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 13930AAC for ; Fri, 9 May 2014 00:31:33 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id B597C1FD47 for ; Fri, 9 May 2014 00:31:32 +0000 (UTC) Message-ID: <1399595490.2230.13.camel@dabdike.int.hansenpartnership.com> From: James Bottomley To: Christoph Lameter Date: Thu, 08 May 2014 17:31:30 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-15" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Sarah Sharp , ksummit-discuss@lists.linuxfoundation.org, Greg KH , Julia Lawall , Darren Hart , Dan Carpenter Subject: Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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