stable.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Sebastian Gottschall <s.gottschall@dd-wrt.com>,
	Harsh Shandilya <msfjarvis@gmail.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: Linux 3.10.108 (EOL)
Date: Sat, 18 Nov 2017 08:31:34 +0100	[thread overview]
Message-ID: <20171118073134.GA18973@1wt.eu> (raw)
In-Reply-To: <20171117234620.064b6498@alans-desktop>

On Fri, Nov 17, 2017 at 11:46:20PM +0000, Alan Cox wrote:
> > > i just wanted to throw some stones on the bloated kernel problem which is
> > > increasing  
> > 
> > People used to be working on that, but then it seemed like the "size"
> > got to a point that people were comfortable with it.  Are you sure that
> 
> There's also a lot of pushback to things that add a ton of ifdefs.
> 
> > just changing some build options would not make your image smaller?
> > Letting people know sometime in the past few years that the kernel was
> > getting "too big" for you would have been good to do :)
> 
> It's also an increasingly hard problem to deal with because the scale of
> big machines means the algorithms themselves in a modern Linux OS just
> don't make sense for a tiddly embedded router.

It's true but it's also true that a lot of these algorithm can be tuned
at build time. We have various memory allocators, tiny RCU, the ability
to disable SMP, we can even tune certain filesystems to use more or less
buffers, etc. It's not that bad at all and I'm not sure that many other
OSes have this level of flexibility.

> I know lots of people build them that way but if you compare it with one
> of the more conservative *BSD builds you have to wonder why not use BSD
> instead - especially with nanoBSD ?

Well, I maintain a kernel image that I use as a bootloader / recovery image
to (re-)install some machines. The kernel+rootfs image fits in 1.7 MB, and
in that size it supports a few network drivers, SATA, serial console, kexec,
EXT2+VFAT and a few other stuff. Obviously it's a bit limited, but it serves
this purpose well as it needs to fit into a 2 MB partition where GRUB is
already installed. It started with 2.6.16 about 12 years ago, then 2.6.35,
now 3.10.104. The image has increased a bit over time, but it also required
a lot less patches to shrink it.

If that can be useful, I can try to port these patches to modern kernels
to get them merged. However some of them add new options (eg: enable
diag/stats in igb driver, etc) and would probably need to be inverted to
disable certain features based on a central option to make the kernel much
smaller.

> (and BSD has the reverse problem - most BSD does not scale to a modern
> bigger machine of course).
> 
> Alan
> "1.2.13 was the last true Linux"  ;-)

I've been using this one for a while and have even deployed it a few times
as LAN->PPP gateways by reconverting old 2 MB RAM 386's (1.6 MB in fact since
384kB were lost and not remappable by then). It was unbeatable for this
purpose, though I'm not aiming at making this possible nowadays, most
machines have at least a bit more RAM :-)

Willy

  reply	other threads:[~2017-11-18  7:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-04 23:06 Linux 3.10.108 (EOL) Willy Tarreau
     [not found] ` <CALpmF+EbmuxvNWiBccGgtw=xDEW1=2hvxfVNp_r4dfiSF2o1UQ@mail.gmail.com>
2017-11-05  7:05   ` Willy Tarreau
2017-11-05  7:46   ` Willy Tarreau
2017-11-14 22:00     ` Sebastian Gottschall
2017-11-14 22:18       ` Willy Tarreau
2017-11-14 22:40         ` Sebastian Gottschall
2017-11-15  4:32           ` Willy Tarreau
2017-11-15  8:09             ` Sebastian Gottschall
2017-11-15  8:50               ` Greg KH
2017-11-17 23:46                 ` Alan Cox
2017-11-18  7:31                   ` Willy Tarreau [this message]
2017-11-20 15:46                     ` Alan Cox
2017-11-18  7:37                   ` Sebastian Gottschall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171118073134.GA18973@1wt.eu \
    --to=w@1wt.eu \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=msfjarvis@gmail.com \
    --cc=s.gottschall@dd-wrt.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).