lkml.org 
[lkml]   [2012]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 06/43] mm: numa: Make pte_numa() and pmd_numa() a generic implementation
    On 11/16/2012 11:56 AM, Mel Gorman wrote:

    >> b33467764d8a mm/migrate: Introduce migrate_misplaced_page()
    >
    > bolts onto the side of migration and introduces MIGRATE_FAULT which
    > should not have been necessary. Already complained about.
    >
    > The alternative uses the existing migrate_pages() function but has
    > different requirements for taking a reference to the page.

    Indeed, NACK to b33467764d8a

    Mel's tree implements this in a much cleaner way.

    >> ca2ea0747a5b mm/mpol: Add MPOL_MF_LAZY
    >
    > We more or less share this except I backed out the userspace visible bits
    > in a separate patch because I didn't think it had been carefully reviewed
    > how an application should use it and if it was a good idea. Covered in an
    > earlier review.

    Agreed, these bits should not be userspace visible, at least
    not for now.

    >> cd203e33c39d mm/mpol: Add MPOL_MF_NOOP
    >
    > I have a patch that backs this out on the grounds that I don't think we
    > have adequately discussed if it was the correct userspace interface. I
    > know Peter put a lot of time into it so it's probably correct but
    > without man pages or spending time writing an example program that used
    > it, I played safe.

    Ditto.

    >> 6fe64360a759 mm: Only flush the TLB when clearing an accessible pte
    >
    > I missed this. Stupid stupid stupid! It would reduce the TLB flushes from
    > migration context.

    However, Ingo's tree still incurs the double page fault for
    migrated pages. Both trees could use a little improvement in
    this area :)

    >> e9df40bfeb25 x86/mm: Introduce pte_accessible()
    >
    > prot_none.

    This one is x86 specific, and would work as well with Andrea's
    _PAGE_NUMA as it would with _PAGE_PROTNONE.

    >> is a good foundation already with no WIP policy bits in it.
    >>
    >> Mel, could you please work on this basis, or point out the bits
    >> you don't agree with so I can fix it?
    >>
    >
    > My main hangup is the prot_none choice and I know it's something we have
    > butted heads on without progress. I feel it is a lot cleaner to have
    > the _PAGE_NUMA bit (even if it's PROT_NONE underneath) and the helpers
    > avoid function calls where possible.

    I am pretty neutral on whether we use _PAGE_NUMA with _PAGE_PROTNONE
    underneath, or the slightly higher overhead actual prot_none stuff.

    I can live with whichever of these Linus ends up merging.

    --
    All rights reversed


    \
     
     \ /
      Last update: 2012-11-16 19:01    [W:3.133 / U:0.772 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site