3rd-party/linux-kernel-module-cheat
1
0
Fork 0
mirror of https://github.com/cirosantilli/linux-kernel-module-cheat.git synced 2026-01-23 02:05:57 +01:00
Code Issues Releases Wiki Activity

cirosantilli2

Browse Source
This commit is contained in:
Ciro Santilli 六四事件 法轮功
2020-08-06 03:00:02 +00:00
parent 476e109c81
commit 85a1ac2cea
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
README.adoc
View File

@@ -25769,7 +25769,7 @@ while aarch64 only 7 minutes.
I had previously documented on README 10 minutes at: 2eff007f7c3458be240c673c32bb33892a45d3a0 found with `git log` search for `10 minutes`. But then I checked out there, run it, and kernel panics before any messages come out. Lol? I had previously documented on README 10 minutes at: 2eff007f7c3458be240c673c32bb33892a45d3a0 found with `git log` search for `10 minutes`. But then I checked out there, run it, and kernel panics before any messages come out. Lol?
Logs of the runs can be found at: https://github.com/cirosantilli-work/gem5-issues/tree/0df13e862b50ae20fcd10bae1a9a53e55d01caac/arm-hpi-slow Logs of the runs can be found at: https://github.com/cirosantilli2/gem5-issues/tree/0df13e862b50ae20fcd10bae1a9a53e55d01caac/arm-hpi-slow
The cycle count is higher for `arm`, 350M vs 250M for `aarch64`, not nowhere near the 5x runtime time increase. The cycle count is higher for `arm`, 350M vs 250M for `aarch64`, not nowhere near the 5x runtime time increase.
@@ -25777,7 +25777,7 @@ A quick look at the boot logs show that they are basically identical in structur
===== gem5 x86_64 DerivO3CPU boot panics ===== gem5 x86_64 DerivO3CPU boot panics
https://github.com/cirosantilli-work/gem5-issues/issues/2 https://github.com/cirosantilli2/gem5-issues/issues/2
.... ....
Kernel panic - not syncing: Attempted to kill the idle task! Kernel panic - not syncing: Attempted to kill the idle task!
@@ -27490,7 +27490,7 @@ error while converting qcow2: Failed to get "write" lock
When doing long simulations sweeping across multiple system parameters, it becomes fundamental to do multiple simulations in parallel. When doing long simulations sweeping across multiple system parameters, it becomes fundamental to do multiple simulations in parallel.
This is specially true for gem5, which runs much slower than QEMU, and cannot use multiple host cores to speed up the simulation: https://github.com/cirosantilli-work/gem5-issues/issues/15[], so the only way to parallelize is to run multiple instances in parallel. This is specially true for gem5, which runs much slower than QEMU, and cannot use multiple host cores to speed up the simulation: https://github.com/cirosantilli2/gem5-issues/issues/15[], so the only way to parallelize is to run multiple instances in parallel.
This also has a good synergy with <<build-variants>>. This also has a good synergy with <<build-variants>>.