On 11.04.2008 [15:24:25 +1000], David Gibson wrote: > 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.
Err, yes. Blame the lack of sleep or something. 4 billion indeed, which, as you noted, is hitting the 32-bit value limit. > > 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. That makes sense. > 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. That's fine. > 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. Yeah, we probably want to use explicitly 64-bit values in a few tests. > 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. I guess the speed-up would be pretty well attenuated in that case -- so perhaps we'll just need to be satisfied that the testcases, even the functional ones, won't be quite so speedy with the gigantic huge pages. Thanks, Nish -- Nishanth Aravamudan <[EMAIL PROTECTED]> IBM Linux Technology Center ------------------------------------------------------------------------- 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
