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


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
here.

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.


ming



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-04-27 01:44    [W:0.075 / U:4.100 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site