[lkml]   [1999]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] kanoj-mm17-2.3.21 kswapd vma scanning protection
    > Kanoj Sarcar wrote:
    > > Explain ... who are the readers, and who are the writers? I think if you
    > > are talking about a semaphore lock being held thru out swapout() in the
    > > try_to_swap_out path, you are reduced to the same deadlock I just pointed
    > > out. I was talking more about a monitor like approach here.
    > The lock is held thru out swapout(), but it is a shared lock: multiple
    > swapper threads can own it. There should be no lock-up.
    > reader: swapper. Reentrancy is not a problem because it is a read-lock,
    > ie shared. The implementation must starve exclusive waiters (ie a reader
    > is allowed to continue even if a writer is waiting).
    > write: everyone who changes the vma list. These functions must not sleep
    > while owning the ERESOURCE (IIRC the NT kernel name) exclusive.
    > I hope I have not overlocked a detail,
    > Manfred

    With an eye partly towards this implementation, I had the page stealer
    code grab vmlist_access_lock, while others get vmlist_modify_lock,
    although in mm.h, both of these reduce to a down() operation.

    The reason I am not very keen on this solution either is if you
    consider process A holding vmlist_access_lock of B, going into swapout(),
    where it tries to get a (sleeping) driver lock. Meanwhile, process B
    has the driver lock, and is trying to grab the vmlist_update_lock on
    itself, ie B, maybe to add/delete the vma. I do not think there is
    such a driver currently though.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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