On Thu, 26 May 2011, Andrea Arcangeli wrote:

> On Thu, May 26, 2011 at 01:13:58PM -0400, Eric B Munson wrote:
> > +#define YES                  "yes"
> > +#define NO           "no"
> 
> Upstream 2.6.39 was changed to 0/1, that differs from 2.6.38 :(. It's
> probably better to support only 0/1 and let it fail on 2.6.38.

Sounds good.

> 
> > +#define TRANS_ENABLE         "/sys/kernel/mm/transparent_hugepage/enabled"
> 
> This sounds ok if you want hugeadm to be able to tweak everything
> (maybe set madvise mode and then use THP only in a few apps with
> madvise through --trans-madvise).
> 
> > +#define TRANS_DEFRAG         "/sys/kernel/mm/transparent_hugepage/defrag"
> > +#define KHUGE_DEFRAG         
> > "/sys/kernel/mm/transparent_hugepage/khugepaged/defrag"
> 
> I'd drop these two, they're too much for debugging, in libhugetlbfs
> context especially I can't see anybody using THP with defrag off that
> turns off compaction and reclaim entirely and just polls the buddy
> allocator. This is more for debugging only, not useful to tweak.

I will remove these two options then.

> 
> > +#define KHUGE_SCAN_PAGES  
> > "/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan"
> > +#define KHUGE_SCAN_SLEEP  
> > "/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs"
> > +#define KHUGE_ALLOC_SLEEP 
> > "/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs"
> 
> This is useful too. These three plus the "/enabled" are the only 4 I'd
> consider worth tweaking not only for debugging.
> 
> > @@ -97,6 +109,20 @@ void print_usage()
> >     CONT("Adjust pool 'size' lower bound");
> >     OPTION("--obey-mempolicy", "Obey the NUMA memory policy when");
> >     CONT("adjusting the pool 'size' lower bound");
> > +   OPTION("--trans-always", "Enable transparent huge pages always");
> > +   OPTION("--trans-madvise", "Enable transparent huge pages with madvise");
> > +   OPTION("--trans-never", "Disable transparent huge pages");
> > +   OPTION("--trans-defrag-always", "Don't limit THP defrag");
> > +   OPTION("--trans-defrag-madvise", "Limit THP defrag to madvise areas 
> > only");
> > +   OPTION("--trans-defrag-never", "Disable defrag during THP allocation");
> > +   OPTION("--khugepaged-defrag-off", "Disable defrag during THP 
> > promotion");
> > +   OPTION("--khugepaged-defrag-on", "Enable defrag during THP promotion");
> > +   OPTION("--khugepaged-pages <pages to scan>", "Number of pages that 
> > khugepaged");
> > +   CONT("should scan on each pass");
> > +   OPTION("--khugepaged-scan-sleep <milliseconds>", "Time in ms to sleep 
> > between");
> > +   CONT("khugepaged passes");
> > +   OPTION("--khugepages-alloc-sleep <milliseconds>", "Time in ms for 
> > khugepaged");
> > +   CONT("to wait if there was a huge page allocation failure");
> 
> Wouldn't it be cleaner to use a "thp" prefix instead of "trans". And
> add the thp prefix to thp-khugepaged too? (but the latter is ok also
> keeping it khugepaged I guess, I'd still s/trans/thp/)

Sure, I will move to the thp leader in all the options.

> 
> > +.B --khugepaged-pages <pages to scan>
> > +
> > +Configure the number of pages that khugepaged should scan on each pass
> > +
> > +.TP
> > +.B --khugepaged-scan-sleep <milliseconds>
> > +
> > +Configure how many milliseconds khugepaged should wait between passes
> > +
> > +.TP
> > +.B --khugepages-alloc-sleep <milliseconds>
> > +
> > +Configure how many milliseconds khugepaged should wait after failing to
> > +allocate a huge page to throttle the next attempt.
> > +
> > +.PP
> >  The following options affect the verbosity of libhugetlbfs.
> 
> Good description.

Thanks, they came straight out of your transhuge.txt ;)

> 
> Thanks,
> Andrea
> 

Attachment: signature.asc
Description: Digital signature

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to