lkml.org 
[lkml]   [2001]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Locking comment on shrink_caches()
    From
       From: Benjamin LaHaise <bcrl@redhat.com>
    Date: Tue, 25 Sep 2001 17:00:55 -0400

    Last time I looked, those patches made the already ugly vm locking
    even worse. I'd rather try to use some of the rcu techniques for
    page cache lookup, and per-page locking for page cache removal
    which will lead to *cleaner* code as well as a much more scalable
    kernel.

    I'm willing to investigate using RCU. However, per hashchain locking
    is a much proven technique (inside the networking in particular) which
    is why that was the method employed. At the time the patch was
    implemented, the RCU stuff was not fully formulated.

    Please note that the problem is lock cachelines in dirty exclusive
    state, not a "lock held for long time" issue.

    Keep in mind that just because a lock is on someone's hitlist doesn't
    mean that it is for the right reasons. Look at the io_request_lock
    that is held around the bounce buffer copies in the scsi midlayer.
    *shudder*

    I agree. But to my understanding, and after having studied the
    pagecache lock usage, it was minimally used and not used in any places
    unnecessarily as per the io_request_lock example you are stating.

    In fact, the pagecache_lock is mostly held for extremely short periods
    of time.

    Franks a lot,
    David S. Miller
    davem@redhat.com

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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