Messages in this thread | | | Date | Mon, 14 Dec 1998 20:25:24 GMT | From | "Stephen C. Tweedie" <> | Subject | Re: PATCH: Raw device IO for 2.1.131 |
| |
Hi,
On Sun, 13 Dec 1998 06:03:52 +0100 (CET), MOLNAR Ingo <mingo@chiara.csoma.elte.hu> said:
> we have to fix page cache writes anyway to go straight to disk, this will > already handle the pindown. (we never drop a dirty page) raw-IO will thus > will be a sendfile() from smallfile-to-bigfile, with the additional logic > of aliasing target logical pages to the source pages. This aliasing is > nontrivial though. (we can represent anonymous user-pages though a special > inode in the page-cache as well, so 'smallfile' or 'anonymous buffer' are > equivalent.)
We already have the swap cache, which does precisely this: swapper_inode is a static inode used to identify swap entries cached in the page cache.
> Thus we have to deal with data-page to data-page IO only. A data-page can > be present, nonpresent, or nonpresent-aliased. Zero-copy is when we do an > IO from a present page to a nonpresent-aliased page.
But as you note the aliasing is *hard*. The entire page cache has an assumption that there is a one-to-one correspondence between cached things and physical pages.
The advantage of a read/write() O_DIRECT API is that it works immediately, even if we go through the page cache (assuming only that we can write through the page cache, and that is really not hard to do).
In this model, an O_DIRECT read(fd) becomes a normal page cache read, followed by either a move of the page from the page cache into the user page tables (if the page->count is 1), or a copy (if more than one). In other words, there's no new IO mechanism and no cache coherency problem. An O_DIRECT write(fd) is an insert of the page into the page cache (copying if it is already there), followed by the page write and rmcache.
Fixing the aliasing issue is non trivial, but we don't need to fix it to have useful O_DIRECT semantics, nor do we need to destroy or bypass the existing IO infrastructure to achieve it.
--Stephen
- 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/
| |