Hi,
On Tue, Oct 17, 2000 at 10:06:35PM +0200, Andrea Arcangeli wrote:
> > also don't see why any bug with kiobufs can't be fixed without the
> > expensive and complex pinning.
>
> IMHO pinning the page in the pte is less expensive and less complex than making
> rawio and the VM aware of those issues.
raw IO will never be aware of the issues at all. It's all done when
we do the page lookup.
What are the VM issues? There are only two left that I know about.
One is the the swap code --- we are evicting swap cache pages without
caring that there may be a user of the page who has written to it
since we did the unmap. We got away with it until now because of the
assumption that shared swap cache was always readonly (anonymous
shared memory cannot swap through the swap cache for precisely this
reason). In current 2.4, this is a trivial assumption to eliminate.
The other VM gotcha is threads plus fork --- a kiobuf mapping is
basically equivalent to a temporary shared mapping as far as the page
is concerned, but the vma is not marked shared. So we're left with
the possibility of another thread forking, both MMs getting marked as
COW, and then if the page gets touched by the parent thread first, COW
results in the parent getting a new page and the child process
inheriting the page in which the raw IO is still happening.
Does this matter? Maybe, if you want to play kiobuf tricks with
things like pipes and you care about preserving POSIX semantics in all
cases. Not, if you're satisfied with "well, don't do that, it's
stupid!" (Although it _would_ be nice to get the doubled pipe
bandwidth of davem's kiobuf pipes to thoroughly stomp on anybody
else's lmbench numbers...)
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:12 EST