On Thu, Mar 05, 2015 at 09:39:48AM -0800, Linus Torvalds wrote: > Is this really worth it? On real loads? That people are expected to use? I fully agree that it's not worth merging upstream UFFDIO_REMAP until (and if) a real world usage for it will showup. To further clarify: would this not have been an RFC, the patchset would have stopped at patch number 15/21 included. Merging UFFDIO_REMAP with no real life users, would just increase the attack vector surface of the kernel for no good. Thanks for your idea that the UFFDIO_COPY is faster, the userland code we submitted for qemu only uses UFFDIO_COPY|ZEROPAGE, it never uses UFFDIO_REMAP. I immediately agreed about UFFDIO_COPY being preferable after you mentioned it during review of the previous RFC. However this being a RFC with a large audience, and UFFDIO_REMAP allowing to "remove" memory (think like externalizing memory into to ceph with deduplication or such), I still added it just in case there are real world use cases that may justify me keeping it around (even if I would definitely not have submitted it for merging in the short term regardless). In addition of dropping the parts that aren't suitable for merging in the short term like UFFDIO_REMAP, for any further submits that won't substantially alter the API like it happened between the v2 to v3 RFCs, I'll also shrink the To/Cc list considerably. > Considering how we just got rid of one special magic VM remapping > thing that nobody actually used, I'd really hate to add a new one. Having to define an API somehow, I tried to think at all possible future usages and make sure the API would allow for those if needed. > Quite frankly, *if* we ever merge userfaultfd, I would *strongly* > argue for not merging the remap parts. I just don't see the point. It > doesn't seem to add anything that is semantically very important - > it's *potentially* a faster copy, but even that is > > (a) questionable in the first place Yes, we already measured the UFFDIO_COPY is faster than UFFDIO_REMAP, the userfault latency decreases -20%. > > and > > (b) unclear why anybody would ever care about performance of > infrastructure that nobody actually uses today, and future use isn't > even clear or shown to be particualrly performance-sensitive. The only potential _theoretical_ case that justify the existence of UFFDIO_REMAP is about "removing" memory from the address space. To "add" memory UFFDIO_COPY and UFFDIO_ZEROPAGE are always preferable like you suggested. > So basically I'd like to see better documentation, a few real use > cases (and by real I very much do *not* mean "you can use it for > this", but actual patches to actual projects that matter and that are > expected to care and merge them), and a simplified series that doesn't > do the remap thing. So far I wrote some doc in 2/21 and in the cover letter, but certainly more docs are necessary. Trinity is also needed (I got trinity running on the v2 API but I haven't adapted to the new API yet). About the real world usages, this is the primary one: http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg04873.html And it actually cannot be merged in qemu until userfaultfd is merged in the kernel. There's simply no safe way to implement postcopy live migration without something equivalent to the userfaultfd if all Linux VM features are intended to be retained in the destination node. > Because *every* time we add a new clever interface, we end up with > approximately zero users and just pain down the line. Examples: > splice, mremap, yadda yadda. Aside from mremap which I think is widely used, I totally agree in principle. For now I can quite comfortably guarantee the above real life user for userfaultfd (qemu), but there are potential 5 of them. And none needs UFFDIO_REMAP, which is again why I totally agree of not submitting it for merging and it was intended it only for the initial RFC to share the idea of "removing" the memory with a larger audience before I shrink the Cc/To list for further updates. Thanks, Andrea -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
