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

Re: [Xen-devel] Re: [PATCH 0 of 2 V5] libxc: checkpoint compression



On Tue, Nov 8, 2011 at 9:02 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
On Tue, 2011-11-08 at 16:51 +0000, Shriram Rajagopalan wrote:
> On Fri, Nov 4, 2011 at 12:21 PM, Shriram Rajagopalan
> <rshriram@xxxxxxxxx> wrote:
>         Why posix_memalign?
>
>         The compression code involves a lot of memcpys at 4K
>         granularity (dirty pages
>         copied from domU's memory to internal cache/page buffers etc).
>         I would like to
>         keep these memcpys page aligned for purposes of speed. The
>         source pages
>         (from domU) are already aligned. The destination pages
>         allocated by the
>         compression code need to be page aligned.
>
>         correct me if I am wrong:
>          mallocing a huge buffer for this purpose is not optimal.
>         malloc aligns allocations
>          on 16byte (or 8byte) granularity but if a 4K region straddles
>         across two physical
>         memory frames, then the memcpy is going to be suboptimal.
>         OTOH, memalign
>         ensures that we are dealing with just 2 memory frames as
>         opposed
>         to 3 (possible) frames in malloc.
>
>         A simple 8Mb memcpy test shows an average of 500us overhead
>         for malloc
>         based allocation compared to posix_memalign based allocation.
>         While this
>         might seem low, the checkpoints are being taken at high
>         frequency
>         (every 20ms for instance).
>
>         It is not okay to use malloc on other platforms. I simply dont
>         have access to other
>         platforms to test their equivalent versions.  Short of using
>         something
>         like qemu_memalign function.
>
>         I am open to suggestions :)

This is due to minios (aka stubdoms) not having posix_memalign, right?

minios (or rather newlib) does appear to have memalign though, which if
true would also work, right? You could potentially also implement
posix_memalign in terms of memalign on minios and avoid the ifdef.


Sounds good. In that case, can I just post a patch to minios, implementing
posix_memalign and will you then directly take the previous version V4 of this
patch series (the one without #ifdefs) ?

thanks
shriram

Ian.

>
>         shriram
>
>
>
> Ping.
>
>
>         On Fri, Nov 4, 2011 at 5:14 AM, Ian Jackson
>         <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>                 rshriram@xxxxxxxxx writes ("[PATCH 0 of 2 V5] libxc:
>                 checkpoint compression"):
>                 > This patch series adds checkpoint compression
>                 functionality, while
>                 > running under Remus.
>
>                 ...
>                 > Changes since last version:
>                 > 1. use posix_memalign only on linux platforms and
>                 switch to normal malloc for
>                 >    the rest. stubdom compiles successfully.
>
>
>                 Looking at this in more detail, I don't understand why
>                 you're using
>                 posix_memalign rather than just malloc, anyway.  If
>                 it's necessary to
>                 use posix_memalign on Linux, why is it OK to use
>                 malloc on other
>                 platforms ?
>
>                 Also this #ifdef is quite ugly.
>
>                 Ian.
>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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