Messages in this thread | | | Date | Fri, 30 Oct 2009 09:40:37 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: RFC: Transparent Hugepage support |
| |
On Thu, 29 Oct 2009 11:36:58 +0100 Andrea Arcangeli <aarcange@redhat.com> wrote:
> > 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.
Ah, please keep CONFIG_TRANSPARENT_HUGEPAGE for a while. Now, memcg don't handle hugetlbfs because it's special and cannot be freed by the kernel, only users can free it. But this new transparent-hugepage seems to be designed as that the kernel can free it for memory reclaiming. So, I'd like to handle this in memcg transparently.
But it seems I need several changes to support this new rule. I'm glad if this new huge page depends on !CONFIG_CGROUP_MEM_RES_CTRL for a while.
Thanks, -Kame
| |