lkml.org 
[lkml]   [2005]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 2] mm: speculative get_page
    William Lee Irwin III wrote:
    > William Lee Irwin III wrote:
    >
    >>>SetPageFreeing is only done in shrink_list(), so other pages in the
    >>>buddy bitmaps and/or pagecache pages freed by other methods may not
    >
    >
    > On Tue, Jun 28, 2005 at 10:03:00AM +1000, Nick Piggin wrote:
    >
    >>It is also done by remove_exclusive_swap_page, although that hunk
    >>leaked into a later patch (#5), sorry.
    >>Other methods (eg truncate) don't seem to have an atomicity guarantee
    >>anyway - ie. it is valid to pick up a reference on a page that is
    >>just about to get truncated. PageFreeing is only used when some code
    >>is making an assumption about the number of users of the page.
    >
    >
    > tmpfs
    >

    Well it switches between page and swap cache, but it seems to just
    use the normal pagecache / swapcache functions for that. It could be
    that I've got a big hole somewhere, but so far I don't think you've
    pointed oen out.

    >
    > William Lee Irwin III wrote:
    >
    >>>be found by this. There's also likely trouble with higher-order pages.
    >
    >
    > On Tue, Jun 28, 2005 at 10:03:00AM +1000, Nick Piggin wrote:
    >
    >>There isn't because higher order pages aren't used for pagecache.
    >
    >
    > hugetlbfs
    >

    Well what's the trouble with it?

    >
    > William Lee Irwin III wrote:
    >
    >>>page != *pagep won't be reliably tripped unless the pagecache
    >>>modification has the appropriate memory barriers.
    >
    >
    > On Tue, Jun 28, 2005 at 10:03:00AM +1000, Nick Piggin wrote:
    >
    >>There are appropriate memory barriers: the radix tree is
    >>modified uner the rwlock/spinlock, and this function has
    >>a memory barrier before testing page != *pagep.
    >
    >
    > Someone else deal with this (paulus? anton? other arch maintainers?).
    >

    I know what a memory barrier is and does, so you said the
    necessary memory barriers aren't in place, so can you deal
    with it?

    >
    > William Lee Irwin III wrote:
    >
    >>>The lockless radix tree lookups are a harder problem than this, and
    >>>the implementation didn't look promising. I have other problems to deal
    >>>with so I'm not going to go very far into this.
    >
    >
    > On Tue, Jun 28, 2005 at 10:03:00AM +1000, Nick Piggin wrote:
    >
    >>What's wrong with the lockless radix tree lookups?
    >
    >
    > The above is as much as I wanted to go into it. I need to direct my
    > capacity for the grunt work of devising adversary arguments elsewhere.
    >

    I don't think there is anything wrong with it. I would be very
    keen to see real adversary arguments elsewhere though.

    >
    > William Lee Irwin III wrote:
    >
    >>>While I agree that locklessness is the right direction for the
    >>>pagecache to go, this RFC seems to have too far to go to use it to
    >>>conclude anything about the subject.
    >
    >
    > On Tue, Jun 28, 2005 at 10:03:00AM +1000, Nick Piggin wrote:
    >
    >>You don't seem to have looked enough to conclude anything about it.
    >
    >
    > You requested comments. I made some.
    >

    Well yeah thanks, you did point out a thinko I made, and that was very
    helpful and I value any time you spend looking at it. But just saying
    "this is wrong, that won't work, that's crap, ergo the concept is
    useless" without finding anything specifically wrong is not very
    constructive.

    --
    SUSE Labs, Novell Inc.

    Send instant messages to your online friends http://au.messenger.yahoo.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-06-28 03:47    [W:0.026 / U:31.656 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site