lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectLinux-2.3.x: new page locking semantics must break NFS.
    From
    Date

    Hi,

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:0.022 / U:151.616 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site