[lkml]   [2006]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [dm-devel] [RFC] dm-userspace

    On Wed, 2006-04-26 at 16:07 -0700, Dan Smith wrote:
    > MZ> just curious, will the speed be a problem here?
    > I'm glad you asked... :)
    > MZ> considering each time it needs to contact user space for mapping a
    > MZ> piece of data.
    > Actually, that's not the case. The idea is for mappings to be cached
    > in the kernel module so that the communication with userspace only
    > needs to happen once per block. The thought is to ask once for a
    > read, and then remember that mapping until a write happens, which
    > might change the story. If so, we ask userspace again.

    sounds reasonable. saw the caching now.

    > Right now, the kernel module expires mappings in a pretty brain-dead
    > way to make sure the list doesn't get too long. An intelligent data
    > structure and expiration method would probably improve performance
    > quite a bit.
    > I don't have any benchmark data to post right now. I did some quick
    > analysis a while back and found it to be not too bad. When using loop
    > devices as a backing store, I achieved performance as high as a little
    > under 50% of native.

    o. :P 50% is a considerable amount. anyway, good start. ;)

    > MZ> and the size unit is per sector in dm?
    > Well, for qcow it is a sector, yes. The module itself, however, can
    > use any block size (as long as it is a multiple of a sector). Before
    > I started work on qcow support, I wrote a test application that used
    > 2MiB blocks, which is where I got the approximately 50% performance
    > value I described above.

    pure read or read and write mixed?

    > Our thought is that this would mostly be used for the OS images of
    > virtual machines, which shouldn't change much, which would help to
    > prevent constantly asking userspace to map blocks.

    if this is the scenario, then may be more aggressive mapping can be used

    u might have interest on this. some developers are working on a general
    scsi target layer that pass scsi cdb to user space for processing while
    keep data transfer in kernel space. so both of u will meet same overhead
    here. so 2 projects might learn from each other on this.

    ps, trivial thing, the userspace_request is frequently used and can use
    a slab cache.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-04-27 01:44    [W:3.389 / U:0.452 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site