Added a new CC flag into build32 and build64 Makefiles to distinguish
whether compiling to 32-bit or 64-bit code.
[Lionel Debroux: rebased on the memrw functions refactor.]
Signed-off-by: Chao Li <lichao@loongson.cn>
* Add a file containing useful macro definitions, currently a single top-level macro for obtaining the size of an array; use it to replace a sizeof(x) / sizeof(x[0]) construct in system/smbus.c . This requires switching the GCC build mode from C11 to C11 with GCC extensions.
* Initial NUMA awareness (#12) support: parse the ACPI SRAT to build up new internal structures related to proximity domains and affinity; use these structures in setup_vm_map() and calculate_chunk() to skip the work on the processors which don't belong to the proximity domain currently being tested.
Tested on a number of 1S single-domain, 2S multi-domain and 4S multi-domain platforms.
SKIP_RANGE(iterations) trick by Martin Whitaker.
* Optimize the JEP106 list by using __attribute__((packed)) to remove padding. The x86 & x86_64 series support unaligned accesses just fine, after all, and this is not remotely a hot path.
* Optimize several string-related constructs by switching to fixed-length char arrays, which avoids pointers + relocations.
* app/interrupt.c: array of different-length strings, but most of those are lengthy enough for this to be a clear win, especially on x86_64;
* system/usbhcd.c: array of same-length strings;
* tests/tests.h: array of structs containing same-length strings.
* Reduce the size of the list of tests by using a narrower type for the cpu mode, which reduces padding.
* For 64-bit images, use the physical address as the test pattern in test 2.
This will make it easier to diagnose faults.
* Disable test 1 by default (issue #155).
Test 2 provides the same test coverage. Test 1 may make it slightly easier
to diagnose faults with a 32-bit image, so leave it as an option.
* For 32 bit images, use the physical address to generate the offset in test 2.
Detecting a stage change and using that to reset the offset counter
could fail when the config menu was used to skip to the next test
(issue #224).
If the memory map contains very small segments and we have many active CPUs,
the tests that split the segments into chunks distributed across the CPUs may
end up with chunks that are too small for the test algorithm. With 4K pages
and the current limit of 256 active CPUs, this is currently only a problem
for the block move and modulo-n tests, but if we ever support more than 512
active CPUs, it could affect the other tests too.
For now, just skip segments that are too small in the affected tests. As it
only affects the block move and modulo-n tests and only affects very small
regions of memory, the loss of test coverage is negligable.
This may fix issue #216.
* Improve abstraction in vmem.h and limit memory benchmarking to first 2GB.
The third GB may get used for remapping memory regions that are only
accessed during startup, so it's not safe to use it for the memory
speed tests.
* Fix calculation of end limit for locating memory benchmark workspace.
* Document vmem.h.
* Use window number, not current start address, to detect first window.
* Increase the program low-load range from 1MB to 4MB and make more robust.
If the BIOS has reserved some parts of low memory, there may not be
enough contiguous space left to load the program there (issue #49).
So increase the low-load range to include the first 3MB of high
memory. Also guard against the program being initially loaded
straddling the new boundary.
Co-authored-by: Martin Whitaker <memtest@martin-whitaker.me.uk>
The old barrier implementation was very slow when running on a multi-socket
machine (pcmemtest issue 16).
The new implementation provides two options:
- when blocked, spin on a thread-local flag
- when blocked, execute a HLT instruction and wait for a NMI
The first option might be faster, but we need to measure it to find out. A
new boot command line option is provided to select between the two, with a
third setting that uses a mixture of the two.
Mostly we write and read large chunks of data which will make it likely
that the data is no longer in the cache when we come to verify it. But
this is not always true, and in any case, we shouldn't rely on it.
