Date: Mon, 15 Jul 1996 08:31:00 +1000 From: Bruce Evans <bde@zeta.org.au> To: sos@FreeBSD.ORG, toor@dyson.iquest.net Cc: freebsd-hackers@FreeBSD.ORG, joerg_wunsch@uriah.heep.sax.de, jonny@gaia.coppe.ufrj.br, pjchilds@imforei.apana.org.au Subject: Re: Preach it (was Some recent changes to GENERIC) Message-ID: <199607142231.IAA08296@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199607142231.IAA08296>