Subject: [linux-audio-dev] Re: O_DIRECT architecture (was Re: info point on linux hdr)
From: Stephen C. Tweedie (sct_AT_redhat.com)
Date: Tue Apr 18 2000 - 23:22:54 EEST
Hi,
On Tue, Apr 18, 2000 at 01:17:52PM -0500, Steve Lord wrote:
> So I guess the question here is how do you plan on keeping track of the
> origin of the pages?
You don't have to.
> Which ones were originally part of the kernel cache
> and thus need copying up to user space?
If the caller requested O_ALIAS, then the IO routine is allowed to
free any page in the kiobuf and alias the existing page cache page into
the kiobuf. It doesn't actually matter whether the original page in
the page cache was there when we started, or whether it was a kiobuf
page which we mapped into the page cache for a direct IO. The whole
point is that as long as the IO is in progress, it is a perfectly
legal page in the page cache.
There is one nastiness. This use of the kiobuf effectively results
in a temporary mmap() of the file while the IO is in progress. If
another thread happens to write to the page undergoing an O_DIRECT
read, then we end up modifying the page cache. That's bad.
So, we need to make sure that while the IO is in progress for a true
raw IO, we keep the page locked during the IO and mark the page not-
uptodate after the IO completes. That way, even if another process
looks up the page while the IO is in progress, the data that was
undergoing IO will be kept private, and we get a second chance once
the IO has completed to see that the page is now shared and we have
to do a copy.
That is slightly messy, but it nicely hides the transient mmap while
still preserving zero-copy for all of the important cases. It's
about the cleanest solution I can see which preserves complete
cache coherency at all times, because it guarantees that the IO is
always done inside the page cache itself.
> It does not seem hard, just wondering
> what you had in mind. Also, I presume, if the page was already present
> and up to date then on a read you would not refill it from disk - since it
> may be more recent that the on disk data, existing buffer heads would
> give you this information.
It's not a physical buffer_head lookup, it's a logical page cache
lookup that we would do, but yes, we'd read from the page cache in
this case and just do a copy.
> > One consequence is that O_DIRECT I/O from a file which is already cached
> > will always result in copies, but I don't mind that too much.
>
> So maybe an O_CLEANCACHE (or something similar) could be used to indicate
> that anything which is found cached should be moved out of the way (flushed
> to disk or tossed depending on what is happening).
That's an orthogonal issue: posix_fadvise() should be the mechanism for
that if the application truly wants to do explicit cache eviction.
--Stephen
This archive was generated by hypermail 2b28 : Tue Apr 18 2000 - 23:52:56 EEST