Re: Unbloating the kernel, action list
From: Gabriel Paubert
Date: Wed Oct 15 2003 - 18:27:26 EST
On Wed, Oct 15, 2003 at 06:10:15AM -0700, William Lee Irwin III wrote:
> On Tue, 2003-10-14 15:56:38 -0700, cliff white <cliffw@xxxxxxxx>
> >> Marco, if you could supply time on a small client box, and a desired .config,
> >> we can add you as a Tinderbox client,
> >> then you have a place to point people when the size increases.
> On Wed, Oct 15, 2003 at 02:48:42PM +0200, Jan-Benedict Glaw wrote:
> > I can put on the table:
> > 486SLC, 12MB RAM
> > i386, 8MB RAM (hey, this box is nearly build up by discrete parts:)
> > Am386, 8MB RAM
> > P-Classic, 32MB RAM (even that much RAM can go short after an uptme of
> > about a month...)
> > Unfortunately, you need an additional kernel patch because nearly all
> > distros are using mach==i486 which gives you nice sigills on an i386
> > otherwise...
> > MfG, JBG
> Can you quantify the performance impact of cmov emulation (or whatever
> it is)? I have a vague notion it could be hard given the daunting task
> of switching userspace around to verify it.
It can't be cmov emulation since neither 486 or Pentia have cmov, but
one of the following (differences between 386 and 486):
- cmpxchg: not used by UP kernels AFAICT, used by threading libraries,
but maybe it's infrequent enough that it can be emulated
- xadd: can't tell whether it's used, could be emulated in any case
since it looks so rare that you'll have to write specific code
to exercise the emulator ;-)
- bswap: heavily used by network code at least, both applications and
kernel (ntohl/htonl). Emulation would probably be too expensive.
- invlpg: kernel only, easy to test and flush the whole TLB instead,
perhaps even by boot-time patching of the code to minimize size.
(I have no ideas of the number of occurences in an average kernel
but it should be rather small).
- invd/wbinvd: only listed here for completeness :-)
The other problem of the 386 is that it has a fundamental MMU flaw:
no write protection on kernel mode accesses to user space, which makes
put_user() intrinsically racy on a 386 and way more bloated when it is
inlined (access_ok has to call a function which searches the VMA tree).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/