[lkml]   [2009]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC: Transparent Hugepage support
    Hello Ingo, Andi, everyone,

    On Thu, Oct 29, 2009 at 10:43:44AM +0100, Ingo Molnar wrote:
    > * Andi Kleen <> wrote:
    > > > 1GB pages can't be handled by this code, and clearly it's not
    > > > practical to hope 1G pages to materialize in the buddy (even if we
    > >
    > > That seems short sightened. You do this because 2MB pages give you x%
    > > performance advantage, but then it's likely that 1GB pages will give
    > > another y% improvement and why should people stop at the smaller
    > > improvement?
    > >
    > > Ignoring the gigantic pages now would just mean that this would need
    > > to be revised later again or that users still need to use hacks like
    > > libhugetlbfs.
    > I've read the patch and have read through this discussion and you are
    > missing the big point that it's best to do such things gradually - one
    > step at a time.
    > Just like we went from 2 level pagetables to 3 level pagetables, then to
    > 4 level pagetables - and we might go to 5 level pagetables in the
    > future. We didnt go from 2 level pagetables to 5 level page tables in
    > one go, despite predictions clearly pointing out the exponentially
    > increasing need for RAM.

    I totally agree with your assessment.

    > So your obsession with 1GB pages is misguided. If indeed transparent
    > largepages give us real benefits we can extend it to do transparent
    > gbpages as well - should we ever want to. There's nothing 'shortsighted'
    > about being gradual - the change is already ambitious enough as-is, and
    > brings very clear benefits to a difficult, decade-old problem no other
    > person was able to address.
    > In fact introducing transparent 2MBpages makes 1GB pages support
    > _easier_ to merge: as at that point we'll already have a (finally..)
    > successful hugetlb facility happility used by an increasing range of
    > applications.


    > Hugetlbfs's big problem was always that it wasnt transparent and hence
    > wasnt gradual for applications. It was an opt-in and constituted an
    > interface/ABI change - that is always a big barrier to app adoption.
    > So i give Andrea's patch a very big thumbs up - i hope it gets reviewed
    > in fine detail and added to -mm ASAP. Our lack of decent, automatic
    > hugepage support is sticking out like a sore thumb and is hurting us in
    > high-performance setups. If largepage support within Linux has a chance,
    > this might be the way to do it.

    Thanks a lot for your review!

    > A small comment regarding the patch itself: i think it could be
    > simplified further by eliminating CONFIG_TRANSPARENT_HUGEPAGE and by
    > making it a natural feature of hugepage support. If the code is correct
    > i cannot see any scenario under which i wouldnt want a hugepage enabled
    > kernel i'm booting to not have transparent hugepage support as well.

    The two reasons why I added a config option are:

    1) because it was easy enough, gcc is smart enough to eliminate the
    external calls so I didn't need to add ifdefs with the exception of
    returning 0 from pmd_trans_huge and pmd_trans_frozen. I only had to
    make the exports of huge_memory.c visible unconditionally so it doesn't
    warn, after that I don't need to build and link huge_memory.o.

    2) to avoid breaking build of archs not implementing pmd_trans_huge
    and that may never be able to take advantage of it

    But we could move CONFIG_TRANSPARENT_HUGEPAGE to an arch define forced
    to Y on x86-64 and N on power.

     \ /
      Last update: 2009-10-29 11:41    [W:0.024 / U:19.932 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site