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 66422942 for ; Wed, 14 May 2014 02:40:24 +0000 (UTC) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id D7FF41F89A for ; Wed, 14 May 2014 02:40:22 +0000 (UTC) Message-ID: <5372D6E4.2080009@huawei.com> Date: Wed, 14 May 2014 10:37:24 +0800 From: Li Zefan MIME-Version: 1.0 To: James Bottomley References: <1399595490.2230.13.camel@dabdike.int.hansenpartnership.com> In-Reply-To: <1399595490.2230.13.camel@dabdike.int.hansenpartnership.com> Content-Type: text/plain; charset="ISO-8859-1" 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 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.