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 10:04:13
On Sun, 3 Mar 2002, Thor Lancelot Simon wrote:

: > : My $.02: If there isn't already an FAQ entry or some such pointing out
: > : the possible cost of COMPAT_<version> options,
: >
: > There's really nothing significantly performance-impacting in any of the
: > other numeric COMPAT_xx options; the [s]brk() change as proposed would be
: > treading on new ground in that respect.
:
: 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.

Any other option can increase kernel size, so that aspect is not specific to
COMPAT_<number>.

-- 
-- Todd Vierling <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/