From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752829AbdFMHMj (ORCPT ); Tue, 13 Jun 2017 03:12:39 -0400 Received: from mail-wr0-f194.google.com ([209.85.128.194]:33017 "EHLO mail-wr0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752726AbdFMHMh (ORCPT ); Tue, 13 Jun 2017 03:12:37 -0400 Date: Tue, 13 Jun 2017 09:12:28 +0200 From: Ingo Molnar To: Nicolas Pitre Cc: Ingo Molnar , Peter Zijlstra , linux-kernel@vger.kernel.org, Linus Torvalds , Thomas Gleixner Subject: Re: [PATCH v2 0/8] scheduler tinification Message-ID: <20170613071228.aw4z2xra37bci7ua@gmail.com> References: <20170606232450.30278-1-nicolas.pitre@linaro.org> <20170607160010.e2gtddlllflvr6er@gmail.com> <20170608075936.426zbwb63drsemgh@gmail.com> <20170611094206.v5m7d6zvlyw7zibd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Nicolas Pitre wrote: > > A series that shrinks the .text size of the allnoconfig core Linux kernel from 1MB > > to 9.9MB in isolation is not proof. > > I assume you meant 0.9MB. 0.992 MB actually if we apply the ~8k .text savings. 0.9MB would imply 100k of savings on an allnoconfig kernel. > It is no proof of course. But I'm following the well known and proven > "release early, release often" mantra here... unless this is no longer > promoted? I'm following that same pattern: I gave you negative review feedback as early as possible. Fragmention of the scheduler ABI increases complexity and has knock-on costs - and the kernel size reduction for the usecase you cited are still 1-2 orders of magnitude away from making a practical difference. > > There will literally have to be two orders of magnitude more patches than that > > to reach the 32K size envelope, if I (very) optimistically assume that the > > difficulty to shrink code is constant (which it most certainly is not). > > Once again, my goal is _not_ 32KB. > > And I don't intend to shrink code. Most of the time I just want to > _remove_ code. Compiling it out to be precise. The goal of this series > is all about compiling out code. And to achieve that with the scheduler, > I simply moved some code to different source files and not including > those source files in the final build. That keeps the number of #ifdef's > to a minimum but it makes a big diffstat due to the code movement. So I'm fine with most of the code movement - let's try this series without any of the more controversial bits which should make future arguments easier. Thanks, Ingo