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@xxxxxxxxxx
Attachment:
pgp7dCs2rNKzM.pgp
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
