Messages in this thread | | | Date | Fri, 11 Dec 1998 19:20:37 -0800 | From | "David S. Miller" <> | Subject | Re: PATCH: Raw device IO for 2.1.131 |
| |
Date: Thu, 10 Dec 1998 22:33:48 GMT From: "Stephen C. Tweedie" <sct@redhat.com>
This is a test release. All input, bug reports and requests are welcome.
It doesn't handle shared writable pages correctly at all.
In order to handle that you'd have to flush the page table entries for all other processes mapping that shared writable page, and then rerun your page lockdown loop until things converge and the process stabilizes.
That's one solution, another one (which I'd prefer) is to just snapshot the page into freshly allocated one and free this one at the end of the transfer.
Yet another solution is to totally punt on shared writable pages, what do other raw/IO implementations do here?
Another side comment I have is that the code can be significantly fast path'd for the common case by just walking the page tables directly much like copy_page_range() and friends do, I bet this will be several orders of magnitude faster.
I suppose the entry to the fast path can be guarded by checking that at least the VA range of the transfer resides inside one VMA and only one. Make the slow path be your current code, also branch out to the slow path when you find a shared writable page so you only need to be concerned about it in one place.
Finally, I'd put all this lock down pages stuff into a mm/*.c file. I want to use it for networking if it goes in (zero copy TCP, NFS directly into page cache, etc.).
Otherwise, really nice work.
Later, David S. Miller davem@dm.cobaltmicro.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |