On Tue, 2011-11-08 at 17:13 +0000, Shriram Rajagopalan wrote:
> 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) ?
Well, *I* won't be taking any version of the patch but that sounds like
a sane plan to me, assuming V4 builds after your minios patch.
>
> 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
|
Home