tomaka / redshirt

🧑‍🔬 Operating system
GNU General Public License v3.0
1.43k stars 37 forks source link

CPU caching meta-issue #400

Open tomaka opened 4 years ago

tomaka commented 4 years ago

CPUs typically have cache lines. For performance reasons, it is normally a good idea to not flush these cache lines too often. Consequently, it would be a good idea to be able to "pin" a process (and later a thread) to a specific CPU.

Additionally, we would like to use the CPU's write cache as well. In other words, CPUs should ideally be able to write in the cache line only and not immediately in memory. This means, however, that cache lines must be manually flushed when a process/thread is to be switched to a different CPU, otherwise the new CPU will not see what the previous CPU has written.

In terms of API, this could be handled by passing a "current CPU ID" parameter to the various run methods. The implementation would preferably pick a process that was already on that CPU before. An event would be reported if a process has to be switched to a new CPU.

As for flashing cache lines manually, we should eventually have a custom implementation of the AllocRef trait that tracks which cache lines are in use, and make the Wasm interpreter use this allocator.

EDIT: all this is wrong

tomaka commented 4 years ago

Note that this is an important but very long term issue. At the moment, everything is marked "strong uncachable" on x86. In other words, things are super slow but working.

As an intermediary step, we can use the "write protected" caching mode, which should be fine.