On Thu, Apr 10, 2008 at 08:40:58PM -0700, Nishanth Aravamudan wrote:
> Hi all,
>
> So, while testing on Jon's box with 16G pages, I'm noticing how long
> some of the functional tests can take with this large of a hugeapge
> (readback, for instance). That's because we write the entire hugepage,
> one unsigned int at a time, in this case something like 250 million
> iterations? That seems a little excessive...
250 million? More like 4 billion, I think you'll find.
> Should we just try to check the beginning, middle and end in the case of
> redback()? How about other tests, do we want to make the functional
> ones, at least, run quickly with these gigantic hugepage sizes?
I don't think that's a very good idea, at least not without some
refinement. One thing the readback test is designed to check for is
that there is no internal aliasing within the (supposed) hugepage.
This can happen reasonably easily (on a fair variety of hardware) if
the kernel MM code gets the hugepage handling sort of but not quite
right. That's why it runs a value ramp across the whole page.
Furthermore, it's reasonably plausible that kernel bugs (say the wrong
shift value somewhere in the fault handler) could cause this sort of
aliasing at any power of 2 boundary between the normal page size (or
even below) up to the hugepage size. Therefore, I think it's risky to
leave out big chunks of the page in the readback test.
Of course the ramp counter is only 32-bit and each value is 4 bytes,
so a 16G page uses the whole ramp; any bigger and it won't be able to
detect sufficiently large aliases. Changing it to a 64-bit counter
might be wise at some point.
If we want to speed this up, rather than skipping chunks of the page,
what I'd suggest instead is increasing the stride a bit. Even that's
a little risky, but should be reasonably safe if we don't go too far -
keep the stride to a handful of cachelines, certainly less that a
normal page size.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
