mirror of
https://github.com/cirosantilli/linux-kernel-module-cheat.git
synced 2026-01-23 02:05:57 +01:00
document sched_getcpu.c with gem5 userland
This commit is contained in:
29
README.adoc
29
README.adoc
@@ -10873,7 +10873,9 @@ At 369a47fc6e5c2f4a7f911c1c058b6088f8824463 + 1 QEMU appears to spawn 3 host thr
|
|||||||
|
|
||||||
gem5 user mode multithreading has been particularly flaky compared <<qemu-user-mode-multithreading,to QEMU's>>, but work is being put into improving it.
|
gem5 user mode multithreading has been particularly flaky compared <<qemu-user-mode-multithreading,to QEMU's>>, but work is being put into improving it.
|
||||||
|
|
||||||
In gem5 syscall simulation, the `fork` syscall checks if there is a free CPU, and if there is a free one, the new threads runs on that CPU. Otherwise, the `fork` call, and therefore higher level interfaces to `fork` such as `pthread_create` also fail and return a failure return status in the guest.
|
In gem5 syscall simulation, the `fork` syscall checks if there is a free CPU, and if there is a free one, the new threads runs on that CPU.
|
||||||
|
|
||||||
|
Otherwise, the `fork` call, and therefore higher level interfaces to `fork` such as `pthread_create` also fail and return a failure return status in the guest.
|
||||||
|
|
||||||
For example, if we use just one CPU for link:userland/posix/pthread_self.c[] which spawns one thread besides `main`:
|
For example, if we use just one CPU for link:userland/posix/pthread_self.c[] which spawns one thread besides `main`:
|
||||||
|
|
||||||
@@ -10910,6 +10912,29 @@ gem5 syscall emulation does show the expected number of cores when queried, e.g.
|
|||||||
|
|
||||||
outputs `1` and `2` respectively.
|
outputs `1` and `2` respectively.
|
||||||
|
|
||||||
|
This can also be clearly by running `sched_getcpu`:
|
||||||
|
|
||||||
|
....
|
||||||
|
./run \
|
||||||
|
--arch aarch64 \
|
||||||
|
--cli-args 4 \
|
||||||
|
--cpus 8 \
|
||||||
|
--emulator gem5 \
|
||||||
|
--userland userland/linux/sched_getcpu.c \
|
||||||
|
;
|
||||||
|
....
|
||||||
|
|
||||||
|
which necessarily produces an output containing the CPU numbers from 1 to 4 and no higher:
|
||||||
|
|
||||||
|
....
|
||||||
|
1
|
||||||
|
3
|
||||||
|
4
|
||||||
|
2
|
||||||
|
....
|
||||||
|
|
||||||
|
TODO why does the `2` come at the end here? Would be good to do a detailed assembly run analysis.
|
||||||
|
|
||||||
====== gem5 se.py user mode with 2 or more pthreads fails with because simulate() limit reached
|
====== gem5 se.py user mode with 2 or more pthreads fails with because simulate() limit reached
|
||||||
|
|
||||||
See bug report at: https://github.com/cirosantilli/linux-kernel-module-cheat/issues/81
|
See bug report at: https://github.com/cirosantilli/linux-kernel-module-cheat/issues/81
|
||||||
@@ -17332,6 +17357,8 @@ and:
|
|||||||
1
|
1
|
||||||
....
|
....
|
||||||
|
|
||||||
|
Due to the way that <<gem5-syscall-emulation-multithreading>> however, the output is more deterministic in that case, see that section for further details.
|
||||||
|
|
||||||
=== Linux calling conventions
|
=== Linux calling conventions
|
||||||
|
|
||||||
A summary of results is shown at: xref:table-linux-calling-conventions[xrefstyle=full].
|
A summary of results is shown at: xref:table-linux-calling-conventions[xrefstyle=full].
|
||||||
|
|||||||
Reference in New Issue
Block a user