GSOC 2013 project " Kernel Size Reduction for Embedded System "

[Alfred Perlstein]

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