[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Size of MirageOS, too big now?


To dynamically enable -use-lto you can use 'env OCAMLPARAM=use-lto=1,_ mirage build'.
Using that command + 'strip -s' I'm not getting the same numbers as you:

         | no lto | no lto+strip | lto | lto+strip
 noop    | 2.4M   |   1.4M       | 1.1M| 668K
 network | 4.3M   |   2.5M       | 1.9M| 1.1M

There's room for improvement in the lto patch so hopefully we can get these numbers down.

Regarding bytecode execution, you can tell OCaml to generate a C file in which the bytecode is embedded (-custom -output-obj -o <name>.c).
This exposes a 'caml_startup' function.
After that you just need to link with 'libcamlrun.a' (216K).

Le 2019-02-14 06:53, Hiroshi Doyu a écrit :
Hello Anil,

Recently Linux *kernel*(IoT for Linux, IoTL) has been being shrunk
around 1MB runtime RAM and its minimal system can run with a few MB of
RAM[1]. So it would be nice if "MirageOS with UDP stack" runs with
smaller RAM than IoTL, probably around 1MB?

Yesterday, I found the following. Quite close to the above ~1MB target
with '-use-lto':

~/src/mirage-skeleton/device-usage/network$ du -h network.hvt 
1.6M    network.hvt

Doesn't bytecode require runtime(ocamlrun?) installed too?

$ objdump -b binary -s hello.byte | head -7
 0000 23212f68 6f6d652f 65686972 646f792f  #!/home/ehirdoy/
 0010 2e6f7061 6d2f342e 30362e31 2f62696e  .opam/4.06.1/bin
 0020 2f6f6361 6d6c7275 6e0a5400 0000df02  /ocamlrun.T.....

$ strip -s ocamlrun && du -h ocamlrun # dynamically linked, though....
268K    ocamlrun

So you suggested to use native code. As far as I understand, '-use-lto'
option stripped off unused modules. It's quite nice. Is there any
ocamlclean(stripping off unused functions?) for native? Because
MirageOS is statically linked, there's no point to have unused
functions in it(?)

[1] https://schd.ws/hosted_files/elciotna18/67/opdenacker-size-bof.pdf


On Wed, 2019-02-13 at 10:25 -0800, Anil Madhavapeddy wrote:
From a quick look at the symbol map, I suspect that moving the OS
to module aliases and Dune virtual_modules will help eliminate some
dependencies.  The 500KB->960KB isn’t too far off the mark; there are
to Ipaddr and Lwt that would account for the increase.

It would be helpful to know what you’re aiming for — as small as
without a performance hit? Bytecode (as we experimented with in the
paper) is very slow for production use, and so hasn’t been maintained
ocaml-freestanding.  For native, how small is small enough for your

MirageOS-devel mailing list

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.