Date: Wed, 26 Feb 2014 14:24:45 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Warner Losh <bsdimp@gmail.com>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: arch@freebsd.org Subject: Re: small kernel kernel option... Message-ID: <20140226222445.GD92037@funkthat.com> In-Reply-To: <CA%2BhQ2%2BiEmvTfRd%2B7k3mZjWdDBgFqxBHnq4fj5M6=BwhaoP08Qg@mail.gmail.com> <5BA6FA29-0BBE-45C1-B734-29013C5A2D29@bsdimp.com> References: <20140226214816.GB92037@funkthat.com> <CA%2BhQ2%2BiEmvTfRd%2B7k3mZjWdDBgFqxBHnq4fj5M6=BwhaoP08Qg@mail.gmail.com> <20140226214816.GB92037@funkthat.com> <5BA6FA29-0BBE-45C1-B734-29013C5A2D29@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote this message on Wed, Feb 26, 2014 at 14:02 -0800:
>
> On Feb 26, 2014, at 1:48 PM, John-Mark Gurney <jmg@funkthat.com> wrote:
>
> > I'm about to commit a change to sha256 to speed it up, but the cost
> > of that speed up is an increase in code/data size from just under 1k
> > to almost 9k (as measured on amd64)... this increase is from unrolling
> > a loop..
> >
> > Maybe we should have a global kernel option, SMALL_KERNEL, or something
> > similar that can be used to shrink code size for those that are trying
> > to build small embedded devices?
>
> I?d prefer something that?s more like OPTIMIZE_SIZE or OPTIMIZE_SPEED.
Shall I add OPTIMIZE_SIZE and make OPTIMIZE_SPEED the default (by being
unspecified)? I don't know of a good way w/ config to make sure only
one or the other is specified (besides having some shared header #error
if they are.. and though you could say if neither is specified, balance
that optimization, but I don't see a use for it...
> > Or do we already have this option, but I just don't know about it?
>
> We don?t have it. We have a billion tiny knobs.
Then we could through a bunch of those knobs under an #ifdef
OPTIMIZED_SPEED block..
> > I know 8k isn't much, but, a billion here and a billion there and pretty
> > soon you're talking about real money.. :)
>
> yea? There?s lots that can be done here, since most folks don?t bother with this?
Every little bit helps... :)
Luigi Rizzo wrote this message on Wed, Feb 26, 2014 at 14:05 -0800:
> It is very nice that you care about this.
> I am just not really sure that for such small numbers the extra data size
> matters much. The downside, as you can imagine, is now having to make sure
> that lint kernels do not trip on some "unused" warning.
I do know that there are some people trying to fix a bootable image
in really small flash, like 4meg or something like that, so 8k is
.2% of 4meg, so it is something... I do think we could save more
space by making some standard things optional, or detecting when code
isn't used and isn't part of the public KPI, but we have to start
somwhere...
Catching build errors shouldn't be too bad as I'm sure we'll have a few
arm kernels add this option almost immediately... It does mean we
either need to add a LINT-SPEED kernel like we have -NOINET, -NOIP,
etc. or simply let tinderbox catch these...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140226222445.GD92037>