From owner-freebsd-embedded@FreeBSD.ORG Thu Mar 28 04:23:34 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 7E4E4738; Thu, 28 Mar 2013 04:23:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E25B973E; Thu, 28 Mar 2013 04:23:33 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id r3so4067685wey.17 for ; Wed, 27 Mar 2013 21:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sVLGrZbX7sznFHGRq1mD/XsfMG/e3cxPBP4EPxjwxlg=; b=nS4GXc+L3UZoXlOD93KZa1frHWO3elbPnntAgWEebJ7S/cHzXdGn6BZAwaUH3gcMSn yeIBH1brId7ka/5Y8kFxpUcP/pYmLqKHjYspnU2m65QAeUqTntM781/BGNBwO8tBx7yA Ek92unVnQzfPwJX18I3B4+0n4dzx3uM3tv5cjsu10V7xUUeK28BDLVCOQJfUZ4AHkYmP sHGXPGaqhwuOyPTe3mPw5RZeEwglt7MrwmwVc6nL5i05DJP64AZFm8PLHWQGdgPZuFIj h+IfgzVlQ6Ob/4HojR32lPumm1BikYjnDDY+8sW+vHD4xExNykPN8F83xTwLmnx4NWat +A6w== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr35347110wjc.0.1364444612235; Wed, 27 Mar 2013 21:23:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Wed, 27 Mar 2013 21:23:32 -0700 (PDT) In-Reply-To: References: <1364404612.36972.59.camel@revolution.hippie.lan> <65064C0E-1C1F-4C07-9CFB-DEEC1638A78D@bsdimp.com> Date: Wed, 27 Mar 2013 21:23:32 -0700 X-Google-Sender-Auth: y2YV4Y2Fn3ym6WMxcjx9xpJGU0w Message-ID: Subject: Re: FreeBSD on the AP121 (AR9330) From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 04:23:34 -0000 On 27 March 2013 20:22, Warner Losh wrote: > I was able to save about 40k by uninlining mutexes, etc. But that took th= e AP96 kernel from 6.5MB to 6.4MB. 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. > 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 Ok, I'll try that. I wonder how badly it's going to affect performance though. :-( > Here's the top 10 in terms of text size: > > 57344 160 49184 106688 1a0c0 /dune/imp/obj/mips.mips/dune/imp/= FreeBSD/sys/AP96/kern_umtx.o This is likely due to the default size of the mtx array. I dropped that from 512 to 64, no appreciable drop. :-( > 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 > > two of which you might be able to do something about. One suspects that P= CIe support could be compiled out of pci.o, and there's two from CAM, and a= nother three from file systems... Maybe there's a smaller subset of CAM tha= t can be compiled in for the USB drive support? The AR724x uses PCIe; so I can't kill that. 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. > Last time I fought this battle, it was a battle of attrition: 20k here, 2= 0k there, 5k over there. Sadly, you'll need about 100 of these. Also, inli= ning can cause significant bloat, and we inline a lot... 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. 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. Sniffle. :-( I really could do with some more help here. Adrian Adrian