Re: [PATCH 00 of 41] Transparent Hugepage Support #17

[Avi Kivity <avi@redhat.com>]

On 04/11/2010 02:24 PM, Ingo Molnar wrote:
> * Andrea Arcangeli<aarcange@redhat.com>  wrote:
>
>    
>> So this takes more than 2 seconds away from 24 seconds reproducibly, and it
>> means gcc now runs 8% faster. [...]
>>      
> That's fantastic if systematic ... i'd give a limb for faster kbuild times in
> the>2% range.
>
> Would be nice to see a precise before/after 'perf stat' comparison:
>
>      perf stat -e cycles -e instructions -e dtlb-loads -e dtlb-load-misses --repeat 3 ...
>
> that way we can see that the instruction count is roughly the same
> before/after, the cycle count goes down and we can also see the reduction in
> dTLB misses (and other advantages, if any).
>
> Plus, here's a hugetlb usability feature request if you dont mind me
> suggesting it.
>
> This current usage (as root):
>
>      echo never>  /sys/kernel/mm/transparent_hugepage/enabled
>
> is fine for testing but it would be also nice to give finegrained per workload
> tunability to such details. It would be _very_ nice to have app-inheritable
> hugetlb attributes plus have a 'hugetlb' tool in tools/hugetlb/, which would
> allow the per workload tuning of hugetlb uses. For example:
>
>      hugetlb ctl --never ./my-workload.sh
>
> would disable hugetlb usage in my-workload.sh (and all sub-processes).
> Running:
>
>      hugetlb ctl --always ./my-workload.sh
>
> would enable it. [or something like that - maybe there are better naming schemes]
>    

I would like to see transparent hugetlb enabled by default for all 
workloads, and good enough so that users don't need to tweak it at all.  
May not happen for the initial merge, but certainly later.


-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>