From owner-freebsd-hackers  Sun Jul 14 15:43:46 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id PAA06804
          for hackers-outgoing; Sun, 14 Jul 1996 15:43:46 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA06796;
          Sun, 14 Jul 1996 15:43:43 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id IAA08296; Mon, 15 Jul 1996 08:31:00 +1000
Date: Mon, 15 Jul 1996 08:31:00 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607142231.IAA08296@godzilla.zeta.org.au>
To: sos@FreeBSD.ORG, toor@dyson.iquest.net
Subject: Re: Preach it (was Some recent changes to GENERIC)
Cc: freebsd-hackers@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de,
        jonny@gaia.coppe.ufrj.br, pjchilds@imforei.apana.org.au
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>If I remove all __inlines in pmap.c, I can save about 3K.  Maybe we
>should/shoundn't have a "SMALL_KERNEL" option?

It would probably be faster too.  Large inlines are often slower because
they bust caches.  3K is too much for the 8K combined I&D L1 cache on
486's - if the 3K is all executed often then it busts the cache, and if
it isn't all executed often then inlining (all of) it just wastes space
when it isn't executed and depletes the caches when it is executed (if a
function version if it would be in a cache).

Other large modules probably suffer from too many macros and inlines.  I
think nfs_serv.c and nfs_vnops.c use too many macros and syscons.c uses
too many macros and inlines.  I'm most familiar with syscons.  The
mark_for_update() macro is a little to be large to be a macro.  The
move_crsr() inline function is much too large to be inline.  These
macros and functions are used a lot in rarely executed code.  The
draw_cursor() inline function is huge.

Bruce