Re: [MirageOS-devel] Mirage/ARM plans

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 14 May 2014, at 18:18, Thomas Leonard <talex5@xxxxxxxxx> wrote:

> On 14 May 2014 16:53, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> On 14 May 2014, at 15:39, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>> 
>>> On 14 May 2014 15:26, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>>>> Note that when I refer to 'libc', I'm really talking about libm (which
>>>>> is essential), a printf implementation, and malloc/calloc.
>>>> 
>>>> Do we steel need the printf stuff for ocaml 4.02 with the new printf's 
>>>> GADTs implementation ?
>>> 
>>> Good point. For now, it's using Mini-OS's printf functions. They
>>> mostly work, but don't recognise %F, for example.
>>> 
>>> For malloc, Mini-OS provides a malloc that returns contiguous regions
>>> of (guest) physical memory (it just calls _xmalloc(size,
>>> DEFAULT_ALIGN)). If OCaml just grabs more memory whenever the heap is
>>> full, that should be fine. If people are freeing stuff, it could
>>> become a problem due to fragmentation.
>> 
>> There's very little mallocing relative to the amount of OCaml heap activity 
>> (which allocates in 2MB chunks by default and could use super pages if 
>> available). So sticking with the simple allocator should be fine for now.
> 
> Good news: it's already using super pages (1MB page table entries
> rather than 4KB). For the 1:1 mapping, that's the easiest thing to do
> anyway.

Splendid!  This is on ARM I assume?  Istr superpage patches on x86_64, but not 
if they were upstreamed. We have a custom patch in the mirage-platform MiniOS 
that should be easy enough to push upstream if not, though.

> 
>> (The exception are perhaps Io_pages which we malloc, but should draw from a 
>> fixed pool to recycle them and not share them with the main heap, since they 
>> can be granted to other driver domains).
>> 
>>> For libm, does anyone have an opinion about openlibm?
>>> 
>>> https://github.com/JuliaLang/openlibm
>>> 
>> 
>> Looks good if it works on ARM (your comment on that issue seems hopefully, 
>> but it's worrying that it's been open for a year).
> 
> Looks like it's just because on ARM long double = double. Should just
> be a case of deleting the extended precision section of the Makefile,
> but I'll have to fix a couple of other things in mirage-platform
> before I can test it.

Sounds good.

cheers,
Anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel