From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 28 14:23:38 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0388F23 for ; Thu, 28 Mar 2013 14:23:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 7E296AF7 for ; Thu, 28 Mar 2013 14:23:38 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id 9so11680927iec.4 for ; Thu, 28 Mar 2013 07:23:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=/3ChaWyIR2MfddfqNhSdKd0ViykFcY7aL//4NHF+J+o=; b=d+grHpu/b++vteZb1oMFYsrRQLKCVFE/TLy7yQmuCOTiNpCQX47nhF/UuuErWO1Io+ MbUUx99f52JSf0JsZUBHEA9WeFF4AsdUGCpXfkVzEnwHWYIfm6VoDx8EYlI3j1Kn1IGp E5eSsnRcC0fBIh3qLYKfa+LWDPU45EZWvBOsceiZJ73mwveAwdHDv51pX6FZtxjoQACF gSn5WUwOFN1GeUWWMPrTapJX0tY1HcTKPH41ZXDcgFgYFJuAg7HNyc1n9yeR/UHkiARs ew18YrGGw1lhq3zYs/KEwGOD61nBNn7/skiF3JWMml974VmGloHOZjD7wE2oQ5PeuEZx 3Jqg== X-Received: by 10.50.106.114 with SMTP id gt18mr7098156igb.23.1364480618192; Thu, 28 Mar 2013 07:23:38 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id y5sm11973809igg.7.2013.03.28.07.23.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Mar 2013 07:23:37 -0700 (PDT) Sender: Warner Losh Subject: Re: FreeBSD on the AP121 (AR9330) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 28 Mar 2013 08:23:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3DAE4BC8-5F03-4DED-B570-5039EE9FFB45@bsdimp.com> References: <1364404612.36972.59.camel@revolution.hippie.lan> <65064C0E-1C1F-4C07-9CFB-DEEC1638A78D@bsdimp.com> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQl7v8YT+2w6xoQZGQe4TJ35tFpBwWeOUzkBTh44wIqYPNzLWopWBdisozEi+9vtQy3TGlKF Cc: freebsd-embedded@freebsd.org, Ian Lepore X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 14:23:38 -0000 On Mar 27, 2013, at 10:23 PM, Adrian Chadd wrote: > On 27 March 2013 20:22, Warner Losh wrote: >=20 >> I was able to save about 40k by uninlining mutexes, etc. But that = took the AP96 kernel from 6.5MB to 6.4MB. >=20 > The AP96 is an all-in-one kernel for a much more useful system. The > AP91 is the kicker. Same architecture, but I have to shrink the kernel > down to fit inside an 896k lzma'ed partition. That, and 16MB of RAM > makes it very, very tight. >=20 >> 4680311 266388 1576752 6523451 638a3b = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/kernel >> 4641469 266372 1576624 6484465 62f1f1 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/kernel >=20 > Ok, I'll try that. I wonder how badly it's going to affect performance > though. :-( On the Atmel AT91RM9200 running at 180MHz it didn't affect things = much... >> Here's the top 10 in terms of text size: >>=20 >> 57344 160 49184 106688 1a0c0 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/kern_umtx.o >=20 > This is likely due to the default size of the mtx array. I dropped > that from 512 to 64, no appreciable drop. :-( Well, the 57k of text isn't going to be affected by that much at all... >> 57004 848 64 57916 e23c = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/pci.o >> 48956 10672 80 59708 e93c = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/scsi_all.o >> 48664 1680 256 50600 c5a8 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/vfs_subr.o >> 45156 624 0 45780 b2d4 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/if_ath.o >> 44932 2000 320 47252 b894 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/vfs_bio.o >> 41796 992 192 42980 a7e4 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/ffs_alloc.o >> 41376 0 0 41376 a1a0 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/if_ath_tx.o >> 38272 5120 80 43472 a9d0 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/kern_jail.o >> 34340 752 192 35284 89d4 = /dune/imp/obj/mips.mips/dune/imp/FreeBSD/sys/AP96/cam_xpt.o >>=20 >> two of which you might be able to do something about. One suspects = that PCIe support could be compiled out of pci.o, and there's two from = CAM, and another three from file systems... Maybe there's a smaller = subset of CAM that can be compiled in for the USB drive support? >=20 > The AR724x uses PCIe; so I can't kill that. Bummer. 56k to implement the pci bus seems large and like there should = be room to trim. > CAM is a big one, unfortunately. It'd be nice if we had a smaller > layer for this but it seems a losing battle without the USB/CAM people > jumping in and considering it as part of their architecture. Well, I'm thinking that there's not much of CAM used for the mass = storage attached via USB that could be conditionally compiled. But I = haven't gone and tried to see where the size bloat comes from and if it = is at all trimmable. >> Last time I fought this battle, it was a battle of attrition: 20k = here, 20k there, 5k over there. Sadly, you'll need about 100 of these. = Also, inlining can cause significant bloat, and we inline a lot... >=20 > The big big thing is how big some of the subsystems are. ~ 200k just > for FFS. ~100k just for uipc routines. mtx is 100k all up and that's > kind of scary. etc. Yes. At one point a lot of that was coming form overly aggressive = inlining. I haven't tried to trim what gets inlined lately though. > It'd be nice if we could trim that much code out of different > subsystems. I'm going to make a concerted effort to shrink down bits > of the wireless stack and ath driver as they're a bit too kitchen sink > for me. But I first need to fit a normal kernel in the damned thing. You can always shrink on larger systems that you artificially constrain = a bit at a time... > Sniffle. :-( I really could do with some more help here. Yea, wish I had more time to actually focus on this... Warner=