-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 DS> I'll take a stab at making this change and will post it when I DS> have something working... I've got a hacked-up version running that allows userspace to provide a pointer to a buffer to be written after the original bio completes. This seems to work pretty well, but I haven't added support to the library or my cow application, so I'm not sure how the performance differs. There is something that needs to be resolved, however. Currently, bio_map_user() assumes it is being run in process context. Since we defer to a kthread for all ring buffer processing, we can't easily construct the extra bios. So, there are two paths forward that I can think of: 1. Redesign how we process messages going to the kernel. Userspace could mark them as "tentatively ready" and then do the write() which just goes through and constructs extra bios and marks them "ready". This seems undesirable to me, because we're increasing the amount of time that userspace is blocked in the kernel. 2. Add a bio_map_user_from() call to the kernel, which behaves just like bio_map_user(), but takes a struct task struct pointer to the process to map from, thus allowing the kthread to construct the bios asynchronously. I have a patch cooked up to do this, but I'm worried that it might be rather controversial. Thoughts? - -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFF2b9PwtEf7b4GJVQRAv7vAJ4uU18Bnm0SSZl+ey6Np2NAf5uDagCdHzRY 0P/AK4VG1H99apotu11toow= =j1Yp -----END PGP SIGNATURE----- -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
