readme: fix some grammar by mistake

README.adoc

@@ -794,7 +794,7 @@ The limitations are severe however:
 * can't <<gdb,GDB step debug the kernel>>, since the source and cross toolchain with GDB are not available. Buildroot cannot easily use a host toolchain: xref:prebuilt-toolchain[xrefstyle=full].
 +
 Maybe we could work around this by just downloading the kernel source somehow, and using a host prebuilt GDB, but we felt that it would be too messy and unreliable.
-* you won't get the latest version of this repository. Our <<travis>> attempt to automate builds failed, and storing a release for every commit would likely make GitHub mad at us anyways.
+* you won't get the latest version of this repository. Our <<travis>> attempt to automate builds failed, and storing a release for every commit would likely make GitHub mad at us anyway.
 * <<gem5>> is not currently supported. The major blocking point is how to avoid distributing the kernel images twice: once for gem5 which uses `vmlinux`, and once for QEMU which uses `arch/*` images, see also:
 ** https://github.com/cirosantilli/linux-kernel-module-cheat/issues/79
 ** <<vmlinux-vs-bzimage-vs-zimage-vs-image>>.
@@ -10677,7 +10677,7 @@ Instead, we have only chip makers, who keep everything that really works closed,
 *** it takes longer to support new hardware features
 --
 +
-Well, not that AOSP is that much better anyways.
+Well, not that AOSP is that much better anyway.
 ** not sure: gem5 has BSD license while QEMU has GPL
 +
 This suits chip makers that want to distribute forks with secret IP to their customers.
@@ -11584,7 +11584,7 @@ This is generally useless compared to checkpoint restoring because:
 * checkpoint restore allows to run multiple contents after the restore, and restoring to multiple different system states, which you almost always want to do
 * we generally don't know the exact tick at which the region of interest will start, especially as the binaries change. It is much easier to just instrument the content with a checkoint <<m5ops,m5op>>
 
-But let's give it a try anyways with link:userland/freestanding/gem5_checkpoint.S[] which was mentioned at <<gem5-checkpoint-userland-minimal-example>>
+But let's give it a try anyway with link:userland/freestanding/gem5_checkpoint.S[] which was mentioned at <<gem5-checkpoint-userland-minimal-example>>
 
 ....
 ./run \
@@ -11723,7 +11723,7 @@ There are two main ways to use m5ops:
 * in bare metal setups
 * when you want to call the instructions from inside interest points of your benchmark. Otherwise you add the syscall overhead to the benchmark, which is more intrusive and might affect results.
 +
-Why not just hardcode some <<m5ops-instructions>> as in our example instead, since you are going to modify the source of the benchmark anyways?
+Why not just hardcode some <<m5ops-instructions>> as in our example instead, since you are going to modify the source of the benchmark anyway?
 
 ==== gem5 m5 executable
 
@@ -17299,7 +17299,10 @@ The example in `man futex` is also a must.
 
 Example: link:userland/linux/sched_getcpu.c[]
 
-Returns the CPU that the process/thread is currently running on: https://stackoverflow.com/questions/491520/how-can-i-get-the-cpu-core-number-from-within-a-user-space-app-linux-c
+Returns the CPU that the process/thread is currently running on:
+
+* https://stackoverflow.com/questions/491520/how-can-i-get-the-cpu-core-number-from-within-a-user-space-app-linux-c
+* https://stackoverflow.com/questions/6026896/how-to-know-on-which-physical-processor-and-on-which-physical-core-my-code-is-ru/16574301#16574301
 
 So when running a multicore program, we may see that each thread can be running on a different core.
 
@@ -21745,7 +21748,7 @@ Sample time on 2017.08: 11 minutes, 7 with full ccache hits. Breakdown: 47% GCC,
 * we have bloated our kernel build 3x with all those delicious features :-)
 * GCC time increased 1.5x by our bloat, but its percentage of the total was greatly reduced, due to new packages being introduced.
 +
-`make graph-depends` shows that most new dependencies come from QEMU and GDB, which we can't get rid of anyways.
+`make graph-depends` shows that most new dependencies come from QEMU and GDB, which we can't get rid of anyway.
 
 A quick look at the system monitor reveals that the build switches between times when: