lkml.org 
[lkml]   [2003]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Unbloating the kernel, action list
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@osdl.org>
> >> 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).

Regards,
Gabriel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.064 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site