From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Scott Subject: Re: [PATCH v2-resend 22/30] libxl: ocaml: event management [and 1 more messages] Date: Tue, 12 Nov 2013 15:49:05 +0000 Message-ID: <52824DF1.2030404@eu.citrix.com> References: <1383760205-20397-1-git-send-email-rob.hoes@citrix.com> <1383760205-20397-19-git-send-email-rob.hoes@citrix.com> <1377168678-25492-1-git-send-email-rob.hoes@citrix.com> <1377168678-25492-23-git-send-email-rob.hoes@citrix.com> <21020.59469.965364.832725@mariner.uk.xensource.com> <21120.60611.692531.460725@mariner.uk.xensource.com> <360717C0B01E6345BCBE64B758E22C2D16EB79@AMSPEX01CL03.citrite.net> <21122.16826.622192.625659@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21122.16826.622192.625659@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson , Rob Hoes Cc: ian.campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Rob Hoes writes ("[Xen-devel] [PATCH v2-resend 22/30] libxl: ocaml: event management"): >> +/* Event handling */ > ... >> +short Poll_val(value event) > ... >> + switch (Int_val(event)) { >> + case 0: res = POLLIN; break; >> + case 1: res = POLLPRI; break; > ... >> +short Poll_events_val(value event_list) > ... >> + while (event_list != Val_emptylist) { >> + events |= Poll_val(Field(event_list, 0)); >> + event_list = Field(event_list, 1); On 12/11/13 14:56, Ian Jackson wrote: > 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 ? > > The result is going to be a lot of consing every time libxl scratches > its nose. In some cases very frequently. For example, if we're > running the bootloader and copying input and output back and forth, > we're using the datacopier machinery in libxl_aoutils.c. That > involves enabling the fd writeability callback on each output fd, > every time data is read from the input fd, and then disabling the > writeability callback every time the data has been written. So one > fd register/deregister pair for every lump of console output. There > are probably other examples. 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 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 :-) 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. Cheers, Dave