From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751871AbdFKJmL (ORCPT ); Sun, 11 Jun 2017 05:42:11 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:32794 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751729AbdFKJmK (ORCPT ); Sun, 11 Jun 2017 05:42:10 -0400 Date: Sun, 11 Jun 2017 11:42:06 +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: <20170611094206.v5m7d6zvlyw7zibd@gmail.com> References: <20170606232450.30278-1-nicolas.pitre@linaro.org> <20170607160010.e2gtddlllflvr6er@gmail.com> <20170608075936.426zbwb63drsemgh@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: > > With the stroke of a pen from the CFO: "yes, we can spend more on our next > > hardware design!" the problem goes away, overnight, and nobody will look back at > > the hardware hack that had only 1MB of RAM. > > Of course hobbyists can already get a Raspberry Pi Zero and run a full > featured Linux distro on it... for a mere 5 bucks. That comes with 512MB > of RAM so my patches certainly don't make a difference there. Note that those mere 5 bucks are probably 50 cents or less in bulk. Perfectly fine economics for many types of 'throw away IoT hardware' products. > But that's not that simple. First there is a fundamental constraint > which is power consumption. If you want your device to run for months > (some will hope years) from the same tiny battery then you just cannot > afford SDRAM. So we're talking static RAM here. And to keep costs down > because you want to give away your thingies by the millions for free it > usually means single-chip designs with on-chip sub-megabyte static RAM. > And in that field the 256KB mark is located towards the high end of the > spectrum. Many IPv6-capable chips available today have less than that. > > And the thing is: people already manage to do a awful lot of stuff in > such a constrained device. Some probably did a good job of it, but most > of them likely suck and we don't know about their bugs because we have > no idea what's running inside. Ok, let me put it this way: there's no way in hell I see a viable Linux kernel running (no matter how stripped down) in 32K or even 64K of RAM. 256K is a stretch as well - but that RAM size you claim to be already 'high end', so it probably wouldn't be used as a standardized solution anyway... Today a Linux 'allnoconfig' kernel, i.e. a kernel with no device drivers and no filesystems whatsoever and with everything optional turned off (including all networking!), is over 2MB large text+data (on x86, which has a compressed instruction set - it would possibly be larger on simpler CPUs): triton:~/tip> size vmlinux text data bss dec filename 926056 208624 1215904 2350584 vmlinux A series that shrinks the .text size of the allnoconfig core Linux kernel from 1MB to 9.9MB in isolation is not proof. 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). I.e. the whole stated premise of the series is wildly not realistic AFAICS, the series does not make Linux more usable at all on that category of devices (Linux is totally inadequate because it's way too large), it only increases its complexity. But you can prove me wrong: show me a Linux kernel for a real device that fits into 32KB of RAM (or even 256 KB) and _then_ I'll consider the cost/benefit equation. Until that happens I consider most forms of additional complexity on the non-hardware dependent side of the kernel a net negative. Thanks, Ingo