> On 23 Apr 1999, Eric W. Biederman wrote:
> >
> > LT> In fact, it already does for NFS, which uses PageLocked for exactly that
> > LT> reason (to serialize read and write requests to the same page).
> >
> > As I understand the NFS code it also tries using PageLocked to
> > synchronize writes _to_ a page from user space.
>
> Yes. It also uses it to synchronize various other write events, like the
> per-page write queue etc.
>
> Once that synchronization has been done, the thing is released: even
> though there is a pending write. It's only a "data coherency lock", it's
> not necessarily a "IO is pending on this" (you could use it for IO pending
> too, but that would serialize everything: releasing the lock means that
> you can gather up multiple write requests up until the time you decide to
> actually physically push it out the door).
For the write gathering and NFSv3 code, the page lock is also held
during the actual WRITE RPC call. The PG_locked in that case means
that either page is being copied, (and the writeback structures are
being set up) or that IO is being done.
Otherwise it obeys the same semantics as the standard kernel (the lock
is still released when the write is pending but not undergoing IO).
> > LT> For "valid to read", you only check Uptodate. For any actual IO
> > LT> (whether it's because you're going to actually _do_ the read or set up
> > LT> some write), PageLocked should be used to synchronize. NFS already does
> > LT> this, and generic_file_read() already understands about it.
> >
> > generic_file_read is quite close but it always does wait_on_page.
> > Not wrong, but not necessary if the page is Uptodate.
>
> I thought I fixed that once already. Oh, well. Minor annoyance and
> potentially a small performance hit (but it shouldn't really be a big
> deal).
Note there is also a small performance hit if we need to wait on the
page in the nfs_readpage, and PG_uptodate is set while we wait: we can
also skip the readpage call in that case. That doesn't affect
'generic_file_read' though, and it's anyway going to be a pretty rare
occurrence...
Cheers,
Trond
-
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/