small kernel kernel option...

[Adrian Chadd]

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 at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"