memory % allocation max / specifying individual CPU cores

[Zack Marsh]

Hello,

I am looking into using stressapptest for server memory testing and have a few questions.

HW/SW info:

     Server: Dell PowerEdge R720

     CPU: E5-2670 (SandyBridge) 2.6GHz -- 8 cores per CPU

     Memory: 256GB (16x16GB 1333 MHz DIMMS)

     OS: SUSE Linux Enterprise Server 11 SP1

     Kernel: 2.6.32.54-XXXXXX

     stressapptest: 1.0.6

Questions:

1. SAT seems to max out at ~79% memory allocation--is it possible to achieve a higher %? Whenever I attempt to set the megabytes of RAM to test higher than 79%, or if I try running the default automatic mode (targeting 94%) I see the following errors:

     Process Error: memalign returned 0

     Process Error: failed to allocate memory

     Process Error: Sat::Initialize() failed

     Status: FAIL - test encountered procedural errors

     Process Error: Fatal issue encountered. See above logs for details.

2. Is it possible to specify which CPU cores to use? For example, if I run the command below I see only see activity on cores 17-32 (as expected) at first (Stats: Starting SAT, 100000M, 30 seconds) using htop, but as soon as the actual testing begins, the work gets spread out across all available cores...

     # taskset 0xffff0000 stressapptest -M 100000 -s 30 -m 32

Many thanks in advance to anyone who could shed some light on these issues.

[Nick Sanders]

Hi Zach, 

1) 

I'm not really sure what's happening here, but there's a couple possibilities. Is your system running some memory or CPU accounting system that restricts single tasks or tasks associated with your login or shell to 80% available memory? Are other apps able to use more memory? 

What's happening here is that your memory allocator (stressapptest is using the default one here) is refusing to allocate memory. Typically this indicates you've run out of virtual address space, or you've run into a system policy limiting memory allocation. It doesn't actually indicate that you don't have free memory, since running out of available memory will cause an OOM rather than an allocation failure. 

2) 

stressapptest tries to distribute threads such that hyperthreaded cpus will have a mix of cpu intensive and memory intensive threads. This code may be interfering with your taskset command. You can check if this is actually the case by running more threads than available cores (say -m 66) which will disable stressapptest's cpu pinning. 

You can also modify the code directly 

https://code.google.com/p/stressapptest/source/browse/trunk/src/sat.cc#1237 and 

https://code.google.com/p/stressapptest/source/browse/trunk/src/worker.cc#427

--
 
---
You received this message because you are subscribed to the Google Groups "stressapptest-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stressapptest-di...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Nick Sanders]

You can also use mapped hugepages which may make large memory systems easier to deal with. 
sudo sysctl -w vm.nr_hugepages=124518 will try to allocate hugepages although a kernel command line may work better.

To unsubscribe from this group and stop receiving emails from it, send an email to stressapptest-discuss+unsub...@googlegroups.com.

[Zack Marsh]

Hi Nick,

Thanks for the responses (sorry mine are late). I discovered the root of the memory allocation issue--as you suspected there was a system policy limiting memory allocation that I needed to adjust.

Also, running stressapptest with more threads than available cores to disabled cpu pinning successfully allowed me to use taskset with stressapptest.