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

FUJITA Tomonori fujita.tomonori at lab.ntt.co.jp
Sun Sep 10 13:34:39 UTC 2006


From: Dan Smith <danms at us.ibm.com>
Subject: [dm-devel] [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





More information about the dm-devel mailing list