> 1) Does not handle writes that straddle multiple VMAs
What exactly do you mean?
If I mmap two areas 1 right after another, then do a write
of comprising of those two areas, your code will only lookup
one of the VMAs.
It's a bug.
> 2) We do not want to encourage people to use this mmap
> scheme anyways. The mmap way consumes precious VM
> space, whereas the sendfile scheme does not.
Is that the answer to my "sendfile is now obsolete"?
It is a "this patch is unacceptable because" comment.
Sure we cannot remove sendfile now, as some applications
depends on it, but that's not what I wanted.
That's not what I'm talking about. I'm saying, making this
mmap thing available makes no sense at all.
I made this patch, so that _portable_ applications (and sendfile
is miles away from beeing portable - even if the target has a
sendfile systemcall, its highly unlikely that it has the same
semantics as Linux' sendfile) are sped up.
This isn't a priority for us. People who want the best possible
performance can code their apps up to take advantage of sendfile()
on systems that have it. (and really, show me how many systems
lack a sendfile mechanism these days).
However, I didn't like the VM waste either, but I believe there
is no other way.
There is a way, convert to sendfile.
Hehe. In fact that wasn't a really serious claim.
Then don't make such claims.
> So I think this patch stinks :)
But it worked? If I didn't misunderstood #1 then I don't see a
problem for integrating it into the current kernel.
I think you need to rethink the multiple VMA case in #1, and
also understand why I don't want this facility in the tree
at all anyways. Apps can convert to sendfile(), and as a result
they'll get improved performance on ALL linux kernels, not just
the ones with your special patch applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/