Date: Tue, 09 Apr 2013 08:43:14 -0700 From: Alfred Perlstein <bright@mu.org> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-hackers@freebsd.org, Amit Rawat <aamitr4@gmail.com>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: GSOC 2013 project " Kernel Size Reduction for Embedded System " Message-ID: <51643712.6010609@mu.org> In-Reply-To: <CAJ-Vmok%2BazFt3Ecym7OgHfwUMD4DrmuWKAzB6qnbR1DmRLpBQA@mail.gmail.com> References: <CAOhv3dpTM9J9oiLpdw8xOAToXT_tQ3VW4Mv1F%2B8n7xhG%2BJK93w@mail.gmail.com> <20130408224423.GA64696@stack.nl> <CAJ-VmonVre%2BVT2tTdQf3hA6DvKifqrJtxDT1RX8KEyW6a-=EXQ@mail.gmail.com> <5163622F.60604@mu.org> <CAJ-Vmok%2BazFt3Ecym7OgHfwUMD4DrmuWKAzB6qnbR1DmRLpBQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/8/13 6:42 PM, Adrian Chadd wrote: > Well, it's relatively easy to experience what it's like. No it's not. We all have jobs that demand different things from us. Taking the time to guess at the problem, only to be told "you're doing it wrong" by someone actually in the position to build the list of requirements is not only a big honking waste of time but not fun nor interesting. Either gather some acceptable feature/performance regressions together that "small" can live with or stop evangelizing. Looking at .o files and guessing what to trim isn't going to work. It sounds like what you want is some magic where you get all the features and your small image while not having to compromise on features/speed. Cool, maybe someone will invent something amazing that gives you less from more, but until then it makes sense to actually be pragmatic and put together a list of things to trim based on sacrifice, not just "because they are big". -Alfred > > Reboot your machine with 32mb. Try to do things like bring up network > interfaces. Snark when stupid stuff occurs, like you can't allocate > enough mbufs for the driver RX path _and_ run the ifconfig command to > completion to bring said interface up. > > There's just a lot of code. You can start by cross-building one of the > MIPS kernels targeting a small system (eg AP121) and look at the > text/data sections of the resulting .o's. Group them together into > subsystems and take a look. > > Now, as for what we can get away with - I'm still going through > another round of review. Yes, there's likely a bunch of syscalls or > syscall behaviours that we just don't need in the embedded world. > Things like all the POSIX compatible fine grained locking? Likely > don't need. But there's some reasonably big areas of bloat that we > could easy hit right now. I've chopped out some of the more silly > abuses in the past (posix acl code that only gets used by ZFS, always > being compiled in? Sigh.) > > Eg: > > text data bss dec hex filename > 59772 160 49184 109116 1aa3c kern_umtx.o > > That's a lot of both code and bss just for mutex handling, don't you > think? Do we really need 59KiB of code and 48KiB of BSS just for mutex > handling? > > text data bss dec hex filename > 184 0 12160 12344 3038 sc_machdep.o > > .. 8 consoles? 12k of BSS? again, not much, but .. > > adrian@lucy:~/work/freebsd/svn/src/sys/cam]> cat > /tmp/AP121-nodebug.txt | egrep 'ata' > text data bss dec hex filename > 11536 0 0 11536 2d10 ata_all.o > 17624 1504 16 19144 4ac8 ata_da.o > 6388 448 16 6852 1ac4 ata_pmp.o > 18960 304 0 19264 4b40 ata_xpt.o > > .. 52 odd KiB tied up in CAM ATA transport, which we don't use unless > the ATA code is compiled in. It's just sitting there, waiting for an > ATA device to come along. > > lucy# cat /tmp/AP121-nodebug.txt | grep "vfs_" | grep -v devfs | sort -k3 > 4160 48 0 4208 1070 vfs_acl.o > 4752 48 0 4800 12c0 vfs_export.o > 5464 0 0 5464 1558 vfs_extattr.o > 8128 288 0 8416 20e0 vfs_default.o > 11020 160 0 11180 2bac vfs_cluster.o > 7916 96 16 8028 1f5c vfs_lookup.o > 19908 144 16 20068 4e64 vfs_vnops.o > 34504 208 16 34728 87a8 vfs_syscalls.o > 3068 64 32 3164 c5c vfs_hash.o > 22700 208 32 22940 599c vfs_mount.o > 1760 144 160 2064 810 vfs_init.o > 14520 16 160 14696 3968 vfs_mountroot.o > 13996 1568 176 15740 3d7c vfs_cache.o > 64852 1680 256 66788 104e4 vfs_subr.o > 52188 2000 304 54492 d4dc vfs_bio.o > > .. 260KiB just for VFS handling. > > etc, etc. > > I'd love to fix this, but I have to make a choice right now between > porting to more of the Atheros wifi/soc platforms, or tackling this > particular issue. I'd love for others to help out here. I'm sure that > reducing code size in general is going be beneficial on the lower end > platforms, even just in cache savings. > > Thanks, > > > Adrian > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51643712.6010609>