From owner-freebsd-arch@FreeBSD.ORG Wed Feb 26 22:43:27 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43DFDDEC for ; Wed, 26 Feb 2014 22:43:27 +0000 (UTC) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F1A041563 for ; Wed, 26 Feb 2014 22:43:26 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id f11so3123873qae.3 for ; Wed, 26 Feb 2014 14:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=Jc18ZQSr9P88CA6nG4m90YULLrcXDIzSsdyRuC9ztuk=; b=dxkzPMXVSgF4LOXbRTq4F4C5STqKVr6ukskVwOWrCoCMPn22BFsWI8TSzjFmisjjFu BvbEEKu0TGldCkudiAX3eEfTalyy2j4DREFzkhU9RtXNNfRjX/RbwE4sZoVhk4z6CnEx CqUmY0It47b+mxE4v7Fcrc8YpldmV+C1UlJuU3BuhE5Zun9Mk9yEG5C6UwdfN7O8blzF VlVUrZUKeviL1qoZQlk5+aJC5Tad5YKMVsGqihrZTjfykY2u9WsEA8QDEQ8ne9fC0iN/ 24U1+bB/MdSfS/JCtpg0ykKbK2CfdXj96Qd691JYrGyfGZef9mF64AbzApIP3n9fbDwq 0uNg== MIME-Version: 1.0 X-Received: by 10.229.56.200 with SMTP id z8mr14059382qcg.1.1393454605326; Wed, 26 Feb 2014 14:43:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.16.10 with HTTP; Wed, 26 Feb 2014 14:43:25 -0800 (PST) In-Reply-To: <20140226222445.GD92037@funkthat.com> References: <20140226214816.GB92037@funkthat.com> <5BA6FA29-0BBE-45C1-B734-29013C5A2D29@bsdimp.com> <20140226222445.GD92037@funkthat.com> Date: Wed, 26 Feb 2014 14:43:25 -0800 X-Google-Sender-Auth: xl7Cx4zGcxjjmw_h9Rv00TUVzoU Message-ID: Subject: Re: small kernel kernel option... From: Adrian Chadd To: Warner Losh , Luigi Rizzo , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 22:43:27 -0000 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 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 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"