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 -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
