FT> Surely, we need to replace the request list with hash list. I have done that now. It helps performance quite a bit, although it does not perform at the same level with lots of threads. I'll keep working on it. FT> Another possible improvement is that simplifying dmu_ctl_write() FT> by using kernel thread. Now the user-space daemon calls FT> dmu_ctl_write() and does lots of work in kernel mode. It is better FT> for a user-space daemon to just notify kernel of new events, go FT> back to user space, and receive new events from kernel in SMP FT> boxes. I like to create kernel threads, dmu_ctl_write just wakes FT> up the threads, and they call dmu_event_recv(). Yes, I think this would be a good idea. FT> Yep, I dropped some of the features because of my laziness, though FT> if endio means that the kernel notifies user-space of I/O FT> completion, I think that I implemented it. We need more than just notification of endio, but also the ability to delay the endio completion until userspace has acknowledged the endio. This is crucial for us to maintain metadata consistency in the CoW case. FT> One possible feature is support for multiple destinations. If user FT> space can tell kernel to write multiple devices, we can implement FT> kinda RAID daemons in user space. Yes, my original version supported this, which would allow RAID from userspace, as well as lots of other neat tricks :) -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx
Attachment:
pgpbwWZkTTa8O.pgp
Description: PGP signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
