You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that on the SG2042, extensive memory access operations in user mode result in significant time spent in kernel mode. It seems that many page faults are occurring in the kernel.
Typically, page faults happen during the initial memory access or if the system has swap enabled. However, even with swap disabled and after the initial access, there are still numerous page faults. Are these page faults necessary? If not, can they be optimized?
In the previous linux-6.1.55, the speed of concurrent memory access by 64 threads sometimes was even below 10MB/s.(not per thread speed, it's speed of all threads)
Description
I've noticed that on the SG2042, extensive memory access operations in user mode result in significant time spent in kernel mode. It seems that many page faults are occurring in the kernel.
Typically, page faults happen during the initial memory access or if the system has swap enabled. However, even with swap disabled and after the initial access, there are still numerous page faults. Are these page faults necessary? If not, can they be optimized?
Steps to reproduce
pgfault.py
this script help to monitor the pgfault count.
memtest.c
this is the test code to access memory.
Test Results
Test on SG2042 (linux 6.6)
warm up stage
test stage
A large number of pgfaults occur here
Test on x86_64
only warm up stage cause pgfault, test stage no pgfault.
warm up stage
test stage
These 134 pgfaults should not be caused by accessing the data array but by starting the threads.
The text was updated successfully, but these errors were encountered: