USM Test Guide
Comprehensive guide for executing USM system test phases including memory management, event processing, and process coordination.
The USM system requires comprehensive testing across three distinct phases to validate memory management capabilities, event processing, and process coordination. This guide provides detailed instructions for executing each test phase.
Note:
These tests require the USM environment to be fully configured and the kernel module to be successfully loaded. Ensure you have completed the Environment Configuration before proceeding.
Phase 1 : Basic Module and Memory Testing (littleTest)
This initial phase validates the fundamental capabilities of compilation, loading, and basic memory allocation of the USM system.
Terminal Configuration
For comprehensive monitoring and testing, you will need 4 terminals:
Terminal 1 - System Monitoring :
watch -n 1 'echo "=== USM Module Status ===" && lsmod | grep usm && echo && echo "=== Memory Status ===" && cat /proc/meminfo | grep -E "(MemFree|MemAvailable|CmaTotal|CmaFree)" && echo && echo "=== USM Interfaces ===" && ls -la /proc/usm* 2>/dev/null || echo "No USM interfaces" && echo && echo "=== Time: $(date) ==="'
Terminal 2 - Kernel Log Monitoring :
sudo dmesg -wT | grep -E --color=always '(USM|usm|Yo|vmalloc|dma_alloc|Instance.*obliterated|Linking|mapcount|refcount)'
Terminal 3 - Memory Allocator :
cd flusm/Userspace
# Kill existing processes
sudo pkill -f project-2 2>/dev/null || true
# Launch the allocator
sudo ./APIv/project-2 APIv/examples/project-2/cfg/loc_alloc_policy_assignment_strategy.cfg
Terminal 4 - Basic Test Execution :
cd flusm/Userspace
# Exécuter littleTest basique
sudo LD_PRELOAD=./usmTagger ./littleTest 8
Test 1.3 : Basic Functionality
Objective : Validate that the basic littleTest executes correctly and interacts with the USM system.
Execution Commands :
cd flusm/Userspace
sudo LD_PRELOAD=./usmTagger ./littleTest 8
Success Indicators:
- The module loads successfully with the message "Yo! #USMRM"
- Memory allocation falls back to vmalloc if CMA is limited
- Interfaces are created in
/proc/usm*and/dev/USMMcd - Basic memory operations function correctly
Result : PASSED. The basic test demonstrates the fundamental functionality of the USM system.
Phase 2 : Event Processing and Process Coordination (littleTestEvents)
This phase tests the USM system's ability to handle complex memory events and coordinate between multiple processes.
Phase 2 Terminal Configuration
Terminal 1 - Monitoring d'Événements :
watch -n 0.5 'echo "=== USM Events Status ===" && echo "CMA: $(cat /proc/meminfo | grep CmaFree | awk "{print \$2}") kB" && echo "Processes: $(ps aux | grep -c project-2)" && echo "Workers: $(ps aux | grep -E "(Worker|memWorker)" | wc -l)" && echo && echo "=== Recent Events ===" && sudo dmesg | tail -5 | grep -i usm || echo "No recent USM events"'
Terminal 2 - Worker and Event Logs :
sudo dmesg -wT | grep -E --color=always 'Worker|memWorker|bravoZero|processesReceiver|Channel|Legacy|state|Conf|obliterated|Linking'
Terminal 3 - Memory Allocator :
cd ~/your_path/flusm/Userspace
# Kill existing processes
sudo pkill -f project-2 2>/dev/null || true
# Launch the allocator
sudo ./APIv/project-2 test_4mb.cfg
Terminal 4 - Event Generator :
cd flusm/Userspace
# Wait for the allocator to be ready
sleep 3
# Execute the event test
sudo LD_PRELOAD=./usmTagger ./littleTestEvents 12
Test 2.1 : Process Onboarding and Event Processing
Objective : Validate that InstanceUSM can detect, register, and handle page faults from a tagged application.
Observations : InstanceUSM correctly detects the littleTestEvents. process. It assigns the default policy, creates a dedicated "Majordomo" thread, and begins managing page fault events generated by the application's memory accesses.
Success Indicators :
- Worker processes successfully initialized (Worker-1/freePageReceiver, memWorker-0/bravoZero)
- Event processing with messages such as "Channel appended! [Legacy]"
- Memory coordination between processes with state transitions
- Performance metrics reaching or exceeding 500 events/second
Result : PASSED. The event system operates within expected performance parameters, demonstrating low-latency processing.
This complete video demonstrates:
- Worker process initialization with detailed logs
- Real-time event processing showing Channel and Legacy support
- Memory coordinator operations between multiple USM processes
- Performance monitoring of event throughput and latency
Phase 3 : Process Forking and Multi-Process Management (littleTestFork)
This final phase validates USM's management of process creation, inheritance, and complex multi-process scenarios.
Phase 3 Terminal Configuration
Terminal 1 - Process Tree Monitoring :
watch -n 0.5 'echo "=== littleTestFork Process Monitoring ===" && echo "Time: $(date)" && echo && echo "Process Tree USM:" && pstree -p | grep -E "(project-2|littleTest)" 2>/dev/null || echo "No USM processes" && echo && echo "Active USM Processes:" && ps aux | grep -E "(project-2|littleTest)" | grep -v grep | wc -l && echo && echo "CMA Status:" && cat /proc/meminfo | grep CmaFree && echo && echo "Recent Fork Events:" && sudo dmesg | tail -3 | grep -E "(fork|sleeper|waker)" 2>/dev/null || echo "No recent fork events"'
Terminal 2 - Fork and Coordination Logs :
sudo dmesg -wT | grep -E --color=always 'USM|usm|fork|sleeper|waker|christine|mapcount|refcount|obliterated|Linking|Child|Parent|PID|PPID'
Terminal 3 - Allocator and Waker :
cd flusm/Userspace
# Kill existing processes
sudo pkill -f "project-2\|waker" 2>/dev/null || true
sleep 2
# Launch the allocator
sudo ./APIv/project-2 test_4mb.cfg &
sleep 3
# Attempt to launch the waker idf available
sudo ./usmWaker 2>/dev/null || echo "Waker not available, continuing with fork tests"
Terminal 4 - Fork Test Execution :
cd flusm/Userspace
# wait for allocator stability
sleep 5
# Execute the fork test
sudo LD_PRELOAD=./usmTagger ./littleTestFork 12
Test 3.1 : Process Fork Management
Objective : Verify that when a USM-managed process calls fork(), the child process correctly inherits the USM context.
Observations : The child process is successfully created and inherits the USM-managed state from the parent. Both parent and child can continue to operate on their memory regions as expected, with appropriate copy-on-write behavior handled by the system.
Basic Test :
sudo LD_PRELOAD=./usmTagger ./littleTestFork 10
Result : PASSED. Fork operations maintain USM integrity with correct state propagation.
Test 3.2 : Multi-Process Coordination
Objective : Test coordination between multiple USM-managed processes, including the sleeper/waker mechanism.
Observations : The usmWaker correctly monitors and wakes the appropriate InstanceUSM threads in response to events from multiple concurrent process. This demonstrates that the central scheduling and coordination mechanism is scalable and efficient.
Advanced Fork Tests:
# Test 1: simple Fork
sudo LD_PRELOAD=./usmTagger ./littleTestFork 12
# Test 2: Multiple concurrent forks
for i in {1..3}; do
sudo LD_PRELOAD=./usmTagger ./littleTestFork 8 &
sleep 1
done
wait
# Test 3: Parent-Child Coordination
sudo LD_PRELOAD=./usmTagger bash -c '
echo "Parent process: $$"
./littleTestFork 10 &
child_pid=$!
echo "Child PID: $child_pid"
wait $child_pid
echo "Parent-child test complete"
'
Critical Validation Points :
- Fork context inheritance working correctly with USM state propagation
- Functional parent-child coordination with proper resource cleanup
- Operational multi-process synchronization with sleeper/waker mechanisms
- Performance metrics maintaining sub-microsecond coordination latency
Result : PASSED. Multi-process coordination operates as designed, demonstrating USM's sophisticated process management capabilities.
Watch this detailed demonstration of the most complex USM test phase:
- Fork context inheritance demonstrated with parent-child process trees
- Multi-process synchronization showing sleeper/waker coordination
- Resource management during concurrent process operations
- Performance validation under multi-process load scenarios