On Sun, Mar 03, 2002 at 10:04:13AM -0500, Todd Vierling wrote:
> 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.

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!

Thor