Messages in this thread | | | From | Gabriel Paubert <> | Date | Wed, 15 Oct 2003 20:16:58 +0200 | Subject | Re: 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/
| |