Testing Large-Memory Hardware

LSF/MM TOPIC Dave Hansen 3 participants 3 messages Mar 18, 2014 Memory management

Share & tools

Dave Hansen

author

2014-03-18 16:33 UTC #0 lore raw

I have a quick topic that could perhaps be addressed along with the testing topic that Dave Jones proposed. I won't be attending, but there will be a couple of other Intel folks there. This should be a fairly quick thing to address.

Topic:

Fengguang Wu who runs the wonderful LKP and 0day build tests was recently asking if I thought there was value in adding a large-memory system, say with 1TB of RAM. LKP is the system that generates these kinds of automated bug reports and performance tests:

	http://lkml.org/lkml/2014/3/9/201

My gut reaction was that we'd probably be better served by putting resources in to systems with higher core counts rather than lots of RAM.
I have encountered the occasional boot bug on my 1TB system, but it's
far from a frequent occurrence, and even more infrequent to encounter things at runtime.

Would folks agree with that? What kinds of tests, benchmarks, stress tests, etc... do folks run that are both valuable and can only be run on a system with a large amount of actual RAM?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Peter Zijlstra

2014-03-18 16:51 UTC #1 lore raw

Quoted 20 lines · Dave Hansen

I have a quick topic that could perhaps be addressed along with the testing topic that Dave Jones proposed. I won't be attending, but there will be a couple of other Intel folks there. This should be a fairly quick thing to address.
Topic:
Fengguang Wu who runs the wonderful LKP and 0day build tests was recently asking if I thought there was value in adding a large-memory system, say with 1TB of RAM. LKP is the system that generates these kinds of automated bug reports and performance tests:
	http://lkml.org/lkml/2014/3/9/201
My gut reaction was that we'd probably be better served by putting resources in to systems with higher core counts rather than lots of RAM.
I have encountered the occasional boot bug on my 1TB system, but it's
far from a frequent occurrence, and even more infrequent to encounter things at runtime.

Quoted 3 lines

Would folks agree with that? What kinds of tests, benchmarks, stress tests, etc... do folks run that are both valuable and can only be run on a system with a large amount of actual RAM?

We had a sched-numa + kvm fail on really large systems the other day, but yeah in general such problems tend to be rare. Then again, without test coverage they will always be rare, for even if there were problems, nobody would notice :-)

Christoph Lameter

2014-03-18 17:26 UTC #2 lore raw

Quoted 6 lines · Peter Zijlstra

Quoted 6 lines
My gut reaction was that we'd probably be better served by putting resources in to systems with higher core counts rather than lots of RAM.
I have encountered the occasional boot bug on my 1TB system, but it's
far from a frequent occurrence, and even more infrequent to encounter things at runtime.

Quoted 8 lines

Quoted 3 lines
Would folks agree with that? What kinds of tests, benchmarks, stress tests, etc... do folks run that are both valuable and can only be run on a system with a large amount of actual RAM?
We had a sched-numa + kvm fail on really large systems the other day, but yeah in general such problems tend to be rare. Then again, without test coverage they will always be rare, for even if there were problems, nobody would notice :-)

SGI had systems out there up to few PB of RAM. There were a couple of tricks to get this going. Bootup time was pretty long. I/O has to be done carefully. The MM subsystem used to work with these sizes (I have not had a chance to verify that recently).

This was Itanium with 64K page size so you had a factor of 16 less page structs to process. What I saw there is one of the reasons why I would like to see larger page support in the kernel. Managing massive amounts of 4k pages is creation far too much overhead.