Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
Willy Tarreau <[email protected]>
| Newsgroups | org.kernel.vger.linux-api,dev.linux.lists.patches,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jun 04, 2026 at 08:58:33AM -0700, Linus Torvalds wrote: > On Thu, 4 Jun 2026 at 08:53, Willy Tarreau <[email protected]> wrote: > > > > > It looks like you're actually doing exactly the thing that I thought > > > was crazy and wouldn't even work reliably: you change the > > > common_response[] contents dynamically *after* the vmsplice, and > > > depend on the fact that changing it in user space changes the buffer > > > in the pipe too. > > > > No no, it's definitely not doing that (or it's a bug, but it's not > > supposed to happen). I'm perfectly aware that one must definitely not > > do that, and it's a guarantee the user of vmsplice() must provide. > > Whew, good. > > In that case, can you just try the vmsplice patch series (Christian > already found a bug, but I don't think it will necessarily matter in > practice - famous last words) and that test patch of mine, and see if > it all (a) works for you and (b) if you have any numbers for > performance that would be *great*. Yes I wanted to do that and noted it on my todo list yesterday when noticing the ongoing discussion. Just been super busy with yesterday's by-yearly release ;-) But at least I wanted to share quick feedback in this thread about existing uses. > There aren't many obvious splice users out there, and even if they > were to exist they are typically specialized enough that you have to > have a real use case to then tell if the patches make a difference in > real life or not. I totally agree, that's why I want to share some feedback. I remember years ago when splice() was broken in 2.6.25, there were so few users that I was the one reporting an API issue to Eric who addressed it early by lack of users. And I even consider that due to the very few users, it's even acceptable to slightly change the way to use it if it can provide extra guarantees (like requiring a capability to access non-anonymous pages for example). It should not break that many apps, and as long as they can preserve their essential benefits, I think most will be OK to adapt. > So you testing that thing would seem to be a great first test of > whether any of this is realistic.. Absolutely! Willy