|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] tapdisk2 segfaults with xen-unstable+linux-2.6-pvops
On Fri, 2010-02-12 at 08:21 -0500, Sander Eikelenboom wrote:
> Hello Daniel,
>
> Done some benchmarking with bonnie++ and it seems blktap2 at present performs
> slightly better than loopback with raw image files, didn't see crashes or
> other problems so far.
Good to hear. Thanks for the feedback and keep me cc'd if you can.
> Will the disabling of shared mem for blktap2 give a big performance hit ?
Memshr is mainly a h/v extension, only driven by tapdisk.
I didn't catch up on the implementation yet. But the idea is to
establish cow mappings on clean buffers read from shared disk images.
Provided the mappings are shadowed in one way or the other. Think
OS-level pagecache.
It's a really good idea. But unless you're actually running a
significant number of clones from a shared master image it will be
generating nothing but overhead.
I think any non-manual decision on whether to turn it on or off should
reside in the hands of a host agent overseeing the potential benefit.
Which is beyond tapdisk, and certainly beyond a hardcoded Makefile
macro.
Whether crashing or not, the medium term update should turn it into a
proper block driver layer.
Cheers,
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|