Subject: Re: PROPOSAL: removal of brk()/sbrk().
To: Thor Lancelot Simon <tls@rek.tjls.com>
From: Todd Vierling <tv@wasabisystems.com>
List: tech-kern
Date: 03/03/2002 23:06:45
On Sun, 3 Mar 2002, Thor Lancelot Simon wrote:
: > : That's not true. I've seen relatively small differences in kernel size
: > : make dramatic differences in packet forwarding performance on crappy
: > : embedded platforms with small or stupidly-designed caches.
: >
: > Kernel size != code path. The *code* introduced by COMPAT_<number> does not
: > hit performance in any significant way.
:
: That's just false; like all other code, it takes up space, and that can
: really suck.
:
: Since these options are quite simply not useful to whole classes of users,
: and they *do* bloat the kernel, and that *does* hurt performance, we should
: not blindly include them in all of our example configurations; particularly
: not those for small machines!
They're in GENERIC for a reason: those are "generic" configurations meant
to run with nearly all optional components enabled. The same argument could
be made for SYSV*, DIAGNOSTIC, and a host of other options that are unneeded
by the majority of users. Not to mention things that sit in critical code
paths like FFS_EI.
(This is really a matter of differing brain wavelengths further into this
thread. My response was meant to address your initial comment that "the
impact of COMPAT_<number> should be in a FAQ", implying that somehow
COMPAT_<number> had adverse impact other than just added code size.)
--
-- Todd Vierling <tv@wasabisystems.com> * Wasabi & NetBSD: Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/