lkml.org 
[lkml]   [2004]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 230-objrmap fixes for 2.6.3-mjb2
    On Wed, Mar 03, 2004 at 12:44:07PM -0600, Dave McCracken wrote:
    >
    > --On Wednesday, March 03, 2004 19:39:01 +0100 Andrea Arcangeli
    > <andrea@suse.de> wrote:
    >
    > >> What we've actually discussed before was more along the lines of
    > >> PG_locked to match VM_LOCKED, but the main idea was to be able to skip
    > >> over ineligible pages without having ot look up their mappings during
    > >> pageout.
    > >
    > > I'm not very excited using PG_locked for that, that doesn't only mean
    > > "unswappable", it means also that the page is under I/O (or uner some
    > > other operation that needs serialization like unmapping the page) which
    > > is quite a different concept from VM_LOCKED. a wait_on_page would
    > > deadlock on such a PG_locked page, while wait_on_page on a page of a
    > > mlocked vma doesn't normally deadlock.
    > >
    > > But I see what you want to do here, and PG_reserved would be too much
    > > for that since it changes the semantics for cow and free_pages, but
    > > PG_locked doesn't look good enough either, the VM_LOCKED and PG_locked
    > > concept is quite different, PG_reserved and VM_RESERVED is quite close
    > > instead (except for the page->count accounting).
    >
    > Sorry, I misspoke. I didn't mean the current PG_locked. I meant a new
    > flag, or more probably a counter, that represents all the VM_LOCKED regions
    > a page is in.

    ok, you used PG_locked that already exists for another purpose so it was
    not clear, another bitflag would be ok.

    the main remaining issue to solve (and run at runtime) is the logic is
    to keep this flag consistent with all vmas pointing to the page having
    VM_LOCKED set. I'm not sure if it's worth it.

    what we do in 2.4 and that works pretty well, that is simply to refile
    pages into the active list if they're mlocked, so we don't waste too
    much cpu on them since we don't analyze them too often. this should work
    pretty well for everybody, or peraphs google may prefer to have a fully
    consistent PG_mlocked.
    -
    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 14:01    [W:0.034 / U:0.112 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site