Re: slow hugetlb from 2.6.15

["Nish Aravamudan" <nish.aravamudan@gmail.com>]

On 6/27/06, stanojr@blackhole.websupport.sk
<stanojr@blackhole.websupport.sk> wrote:
> hello
>
> look at this benchmark
> http://www-unix.mcs.anl.gov/~kazutomo/hugepage/note.html
> i try benchmark it on latest 2.6.17.1 (x86 and x86_64) and it slow like 2.6.16 on
> that web
> (in comparing to standard 4kb page)
> its feature or bug ?
> i am just interested where can be hugepages used, but if they are slower than
> normal pages its pointless to use it :)

I believe your benchmark is measuring the time in such a way to make
current kernels look worse than older ones.

Basically, newer kernels (the ones that have the performance issue
you're seeing) use demand faulting of hugepages.

Thus, timing only the bench() call, as is done now, causes the newer
kernels to appear to take longer, as the pages must be zero'd, and the
page tables must be set up, as part of the bench() invocation (first
use).

In contrast, the older kernels would have done that up front, and thus
that time was not being accounted for in the bench() run.

There are a few ways to make sure this is the case:

1) Time the mmap, bench and unmap calls all together.

2) Add memset(addr, 1, LENGTH) and memset(addr, 0, LENGTH) calls
*before* bench(), to fault in the hugepages before running bench().

If the numbers return to normal after this, then the analysis above
should be accurate. If not, we do have a problem.

Thanks to Andy Whitcroft and Mel Gorman for insight into the potential problem.

Thanks,
Nish

--
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>