Re: [Xen-devel] [PATCH v2-resend 22/30] libxl: ocaml: event management [and 1 more messages]

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

David Scott writes ("Re: [Xen-devel] [PATCH v2-resend 22/30] libxl: ocaml: 
event management [and 1 more messages]"):
> Rob Hoes writes ("[Xen-devel] [PATCH v2-resend 22/30] libxl: ocaml: 
> event management"):
> > This is quite striking.  You're converting a bitfield into a linked
> > list of consed enums.  Does ocaml really not have something more
> > resembling a set-of-small-enum type, represeted as a bitfield ?
..
> Unfortunately there's no direct support for bitfields in OCaml's heap 
> data representation. The common pattern is to convert bitfields into 
> lists of constructors e.g.
> 
> https://github.com/ocaml/ocaml/blob/trunk/otherlibs/unix/open.c#L74

How sad.

> On the positive side, the GC is optimised specifically for the case of 
> short-lived small objects, since this is what you get when you write a 
> compiler or a theorem prover. An allocation in the minor heap is simply 
> a pointer bump, and the trash is chucked out pretty often. The rule of 
> thumb is that anything which has the allocation profile of a compiler or 
> a theorem prover usually works pretty well :-)

OK :-).

> I think if we're allocating a (shortish) list per "lump" of console I/O 
> we're probably ok since I assume we're allocating and deallocating 
> bigger buffers for the console data anyway. For higher throughput 
> channels (vchan, network, disk etc) I'd go for larger, 
> statically-allocated pools of buffers for the data and use a bigger 
> lump-size to amortize the cost of the metadata handling.

libxl doesn't normally concern itself with the main data path, so
vchan, network and disk i/o aren't a problem.

So, I'm reassured on this point.

The locking question is more difficult, I think.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel