lkml.org 
[lkml]   [2015]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 5/8] mm: move lazily freed pages to inactive list
    From
    Date
    > Even if we're wrong about the aging of those MADV_FREE pages, their
    > contents are invalidated; they can be discarded freely, and restoring
    > them is a mere GFP_ZERO allocation. All other anonymous pages have to
    > be written to disk, and potentially be read back.
    >
    > [ Arguably, MADV_FREE pages should even be reclaimed before inactive
    > page cache. It's the same cost to discard both types of pages, but
    > restoring page cache involves IO. ]

    Keep in mind that this is memory the kernel wouldn't be getting back at
    all if the allocator wasn't going out of the way to purge it, and they
    aren't going to go out of their way to purge it if it means the kernel
    is going to steal the pages when there isn't actually memory pressure.

    An allocator would be using MADV_DONTNEED if it didn't expect that the
    pages were going to be used against shortly. MADV_FREE indicates that it
    has time to inform the kernel that they're unused but they could still
    be very hot.

    > It probably makes sense to stop thinking about them as anonymous pages
    > entirely at this point when it comes to aging. They're really not. The
    > LRU lists are split to differentiate access patterns and cost of page
    > stealing (and restoring). From that angle, MADV_FREE pages really have
    > nothing in common with in-use anonymous pages, and so they shouldn't
    > be on the same LRU list.
    >
    > That would also fix the very unfortunate and unexpected consequence of
    > tying the lazy free optimization to the availability of swap space.
    >
    > I would prefer to see this addressed before the code goes upstream.

    I don't think it would be ideal for these potentially very hot pages to
    be dropped before very cold pages were swapped out. It's the kind of
    tuning that needs to be informed by lots of real world experience and
    lots of testing. It wouldn't impact the API.

    Whether MADV_FREE is useful as an API vs. something like a pair of
    system calls for pinning and unpinning memory is what should be worried
    about right now. The internal implementation just needs to be correct
    and useful right now, not perfect. Simpler is probably better than it
    being more well tuned for an initial implementation too.

    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2015-11-04 23:21    [W:3.387 / U:0.288 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site