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/