Date: Wed, 26 Feb 2014 14:43:25 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Warner Losh <bsdimp@gmail.com>, Luigi Rizzo <rizzo@iet.unipi.it>, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: small kernel kernel option... Message-ID: <CAJ-VmompnKZiPipgMGZP7swhqv%2Bj5HGARZCEfMxPRjvG_4eD%2Bw@mail.gmail.com> In-Reply-To: <20140226222445.GD92037@funkthat.com> References: <20140226214816.GB92037@funkthat.com> <CA%2BhQ2%2BiEmvTfRd%2B7k3mZjWdDBgFqxBHnq4fj5M6=BwhaoP08Qg@mail.gmail.com> <5BA6FA29-0BBE-45C1-B734-29013C5A2D29@bsdimp.com> <20140226222445.GD92037@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I like the idea of optimise_speed versus optimise_size. Thanks for taking the time to at least consider this. :-) -a On 26 February 2014 14:24, John-Mark Gurney <jmg@funkthat.com> wrote: > 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." > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmompnKZiPipgMGZP7swhqv%2Bj5HGARZCEfMxPRjvG_4eD%2Bw>