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

[Lucas Pluvinage <lucas.pluvinage@xxxxxx>]

Hi,

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
>
> Thanks!!
>
> 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
> > module
> > to module aliases and Dune virtual_modules will help eliminate some
> > hard
> > dependencies.  The 500KB->960KB isn’t too far off the mark; there are
> > links
> > to Ipaddr and Lwt that would account for the increase.
> >
> > It would be helpful to know what you’re aiming for — as small as
> > possible
> > without a performance hit? Bytecode (as we experimented with in the
> > ASPLOS
> > paper) is very slow for production use, and so hasn’t been maintained
> > in
> > ocaml-freestanding.  For native, how small is small enough for your
> > purposes?
> >
> > best,
> > Anil
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/mirageos-devel
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel