From: Dan Smith <danms@xxxxxxxxxx> Subject: [PATCH] Latest dm-userspace, with memory reclaim Date: Tue, 29 Aug 2006 09:54:38 -0700 > This is the latest version of dm-userspace. I have added a > (configurable) limit on the number of remap objects the kernel will > maintain in memory before re-using old ones. > > I think it may be beneficial to have a soft and a hard limit on this, > to allow allocation to be done if no remaps can be re-used at a given > point (up to the hard limit). Comments appreciated. How about removing the remap object mechanism? You said that the remap object mechanism improves the performance by avoiding contacting user space for every requests. However, as you see, Xen blktap (contacting user space for every requests) and blkback (doing I/O in kernel) performances are comparable. dm-userspace's poor performance of user space access is due to ioctl, an inefficient interface. The blktap uses shared ring buffer between kernel and user space, which enables us to batch multiple requests without data copies. Here's a patch to remove the remap object mechanism and add replaced ioctl with ring buffer. As you can see, the half of the dm-userspace code is for the remap object mechanism: 99 drivers/md/dm-user.h 544 drivers/md/dm-userspace.c 406 drivers/md/dm-userspace-chardev.c 81 include/linux/dm-userspace.h 1130 total 209 drivers/md/dm-user.h 1171 drivers/md/dm-userspace.c 900 drivers/md/dm-userspace-chardev.c 147 include/linux/dm-userspace.h 2427 total I also uploaded a example program to use the new ring buffer interface: http://www.kernel.org/pub/linux/kernel/people/tomo/dmu/example-rb.c -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
