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

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



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 us ibm com

Attachment: pgpRg0rmJuVqX.pgp
Description: PGP signature


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