[dm-devel] [PATCH] Latest dm-userspace, with memory reclaim

[Dan Smith]

FT> You said that the remap object mechanism improves the performance
FT> by avoiding contacting user space for every requests. However, as
FT> you see, Xen blktap (contacting user space for every requests) and
FT> blkback (doing I/O in kernel) performances are comparable.

You may be right.  I suppose the page cache might serve to prevent
repeated accesses to the same location on disk, thus making the remap
cache mostly unnecessary?

FT> dm-userspace's poor performance of user space access is due to
FT> ioctl, an inefficient interface.

I do not use ioctl; I assume you're talking about the chardev
read/write interface...

Do you have performance metrics that show it performs better without
the remap cache?  I have gathered the following:

dbench to an LVM:  250-300 MB/s
dbench to a dm-user cow, backed by LVM: 200-248 MB/s

Considering one is doing CoW and one is not, would you consider
~50MB/s too much of a hit?

FT> The blktap uses shared ring buffer between kernel and user space,
FT> which enables us to batch multiple requests without data copies.

Well, the remap cache and the read/write interface do as much batching
as possible to reduce communication with userspace.  Requests are
copied to/from the kernel, which I suppose limits performance, but the
request objects are rather small.

FT> Here's a patch to remove the remap object mechanism and add
FT> replaced ioctl with ring buffer.

If performance does not suffer, I would love to remove the remap
cache, as it is really ugly and complicated.  I suppose I have been
under the assumption that it is absolutely necessary to achieve good
performance, but if not, I will be the first to rip it out :)

A performance comparison with/without the remap cache would be
appreciated. 

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20060910/2334dc64/attachment.sig>