On 04/11/2010 02:24 PM, Ingo Molnar wrote:
* Andrea Arcangeli<aarcange@xxxxxxxxxx> 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@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>