Re: Benchmarking objrmap under memory pressure

From: Andrea Arcangeli
Date: Wed Apr 14 2004 - 12:14:05 EST


On Wed, Apr 14, 2004 at 09:42:24AM -0700, Martin J. Bligh wrote:
> > As expected the 6 second difference was nothing compared the the noise,
> > though I'd be curious to see an average number.
>
> Yeah, I don't think either is worse or better - I really want a more stable
> test though, if I can find one.

a test involving less tasks and that cannot take any advantage from the
cache and the age information should be more stable, though I don't have
obvious suggestions.

> Yeah, that's odd.

I just wonder the VM needs a bit of fixing besides the rmap removal, or
if it was just a pure concidence. if it happens again in the -aa pass
too then it may not be a conincidence.

> Because it's frigging hard to make a 16GB machine swap ;-) 'twas just my
> desktop.

mem= should fix the problem for the benchmarking ;)

swapping in general is important for 16GB 32-way too (and that's the
thing that 2.4 mainline cannot swap efficiently, and that's why I had to
add objrmap in 2.4-aa too).

> Yeah, it's hard to do mem= on NUMA, but I have a patch from someone
> somehwere. Those machines don't tend to swap heavily anyway, but I suppose
> page reclaim in general will happen.

I see what you mean with mem= being troublesome, I forgot you're numa=y,
you can either disable numa temporarily, or use the more complex syntax
that you should find in arch/i386/kernel/setup.c, that should work w/o
kernel changes and w/o patches since it simply trimes the e820 map,
everything else numa is built on top of that map, you've just to give
an hundred megs from the start of every node, and hopefully it'll boot ;).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/