Great!

Best wishes,
-- 
Ning Qu (曲宁) | Software Engineer | quning@google.com | +1-408-418-6066


On Fri, Sep 6, 2013 at 4:33 AM, Kirill A. Shutemov <
kirill.shutemov@linux.intel.com> wrote:

> Ning Qu wrote:
> > One minor question inline.
> >
> > Best wishes,
> > --
> > Ning Qu (曲宁) | Software Engineer | quning@google.com | +1-408-418-6066
> >
> >
> > On Sat, Aug 3, 2013 at 7:17 PM, Kirill A. Shutemov <
> > kirill.shutemov@linux.intel.com> wrote:
> >
> > > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> > >
> > > For now, TRANSPARENT_HUGEPAGE_PAGECACHE is only implemented for x86_64.
> > >
> > > Radix tree perload overhead can be significant on BASE_SMALL systems,
> so
> > > let's add dependency on !BASE_SMALL.
> > >
> > > /sys/kernel/mm/transparent_hugepage/page_cache is runtime knob for the
> > > feature. It's enabled by default if TRANSPARENT_HUGEPAGE_PAGECACHE is
> > > enabled.
> > >
> > > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > > ---
> > >  Documentation/vm/transhuge.txt |  9 +++++++++
> > >  include/linux/huge_mm.h        |  9 +++++++++
> > >  mm/Kconfig                     | 12 ++++++++++++
> > >  mm/huge_memory.c               | 23 +++++++++++++++++++++++
> > >  4 files changed, 53 insertions(+)
> > >
> > > diff --git a/Documentation/vm/transhuge.txt
> > > b/Documentation/vm/transhuge.txt
> > > index 4a63953..4cc15c4 100644
> > > --- a/Documentation/vm/transhuge.txt
> > > +++ b/Documentation/vm/transhuge.txt
> > > @@ -103,6 +103,15 @@ echo always
> > > >/sys/kernel/mm/transparent_hugepage/enabled
> > >  echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
> > >  echo never >/sys/kernel/mm/transparent_hugepage/enabled
> > >
> > > +If TRANSPARENT_HUGEPAGE_PAGECACHE is enabled kernel will use huge
> pages in
> > > +page cache if possible. It can be disable and re-enabled via sysfs:
> > > +
> > > +echo 0 >/sys/kernel/mm/transparent_hugepage/page_cache
> > > +echo 1 >/sys/kernel/mm/transparent_hugepage/page_cache
> > > +
> > > +If it's disabled kernel will not add new huge pages to page cache and
> > > +split them on mapping, but already mapped pages will stay intakt.
> > > +
> > >  It's also possible to limit defrag efforts in the VM to generate
> > >  hugepages in case they're not immediately free to madvise regions or
> > >  to never try to defrag memory and simply fallback to regular pages
> > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> > > index 3935428..1534e1e 100644
> > > --- a/include/linux/huge_mm.h
> > > +++ b/include/linux/huge_mm.h
> > > @@ -40,6 +40,7 @@ enum transparent_hugepage_flag {
> > >         TRANSPARENT_HUGEPAGE_DEFRAG_FLAG,
> > >         TRANSPARENT_HUGEPAGE_DEFRAG_REQ_MADV_FLAG,
> > >         TRANSPARENT_HUGEPAGE_DEFRAG_KHUGEPAGED_FLAG,
> > > +       TRANSPARENT_HUGEPAGE_PAGECACHE,
> > >         TRANSPARENT_HUGEPAGE_USE_ZERO_PAGE_FLAG,
> > >  #ifdef CONFIG_DEBUG_VM
> > >         TRANSPARENT_HUGEPAGE_DEBUG_COW_FLAG,
> > > @@ -229,4 +230,12 @@ static inline int do_huge_pmd_numa_page(struct
> > > mm_struct *mm, struct vm_area_str
> > >
> > >  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> > >
> > > +static inline bool transparent_hugepage_pagecache(void)
> > > +{
> > > +       if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE_PAGECACHE))
> > > +               return false;
> > > +       if (!(transparent_hugepage_flags &
> (1<<TRANSPARENT_HUGEPAGE_FLAG)))
> > >
> >
> > Here, I suppose we should test the  TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG as
> > well? E.g.
> >         if (!(transparent_hugepage_flags &
> >               ((1<<TRANSPARENT_HUGEPAGE_FLAG) |
> >                (1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG))))
> >
> > +               return false;
>
> You're right. Fixed.
>
> --
>  Kirill A. Shutemov
>