I've been spending the past week working on NFS for linux-2.3.x, and
have finally gotten round to looking at the new page locking
semantics.
It seems to me that the decision to allow readaheads to be performed
without the page lock being held must break the NFS client, since it
uses the page lock in order to serialize the actual page IO. We rely
on the fact that reading in a page locks the page in order to prevent
any new asynchronous writebacks being scheduled while the read is
going on, and vice-versa.
One solution, would be for the NFS readpage() code to ignore any
readahead requests that are not accompanied by a page lock, but the
decision to lift the kernel lock around page locks means that the read
code can no longer rely on that behaviour (the operation lock page +
call inode->i_op->readpage() not being atomic).
Furthermore, the fact that the readpage() call is still required to
unlock the page after IO completion is inherently wrong, because of
the above fact that readpage() has no way of knowing who locked the
page. Unless we make the 'page->owner' debugging field permanent
--something that will still break asynchronous IO-- unlocking the page
must be done by the generic_file_xxx() function itself.
If the asynchronous networked filesystems are the only ones to have
problems, then I suggest that we define a new page flag that can be
used by these filesystems to serialize page IO independently of
whether the page lock is set or not.
#define PG_IOlock 13
and
#define PageIOLocked(page) (test_bit(PG_IOlock, &(page)->flags))
#define TryIOLockPage(page) (test_and_set_bit(PG_IOlock, &(page)->flags))
#define IOUnlockPage(page) \
do { \
if (!test_and_clear_bit(PG_IOlock, &(page)->flags)) \
PAGE_BUG(); \
wake_up(&(page)->wait); \
} while(0)
Comments?
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/