FWIW, given that you're running a game, and most people run games fullscreen, without anything else going, you can probably get away with not using virtualization, aka eating 100% CPU (or at least 100% of one core)... and even then, with most systems having >4 cores nowadays, you probably needn't worry at all.
But just to clarify the corollary, this implementation is running at around 250kHz (!). You wouldn't viably run Linux like this in a practical context anytime soon.
> you can probably get away with not using virtualization, aka eating 100% CPU (or at least 100% of one core)...
That's not how virtualization works, it's time sliced which is why you can have more vCPUs than physical CPUs. You can also limit the slice utilization to an arbitrary percentage or give it a priority level for scheduling.
> That's not how virtualization works, it's time sliced which is why you can have more vCPUs than physical CPUs. You can also limit the slice utilization to an arbitrary percentage or give it a priority level for scheduling.
At that point though, why bother virtualizing? If you're going for the beige PC look, why not go all the way and emulate an 80486 (or 80386 even) on an IBM PC clone in software running linux 0.01? Performance isn't going to matter too much, so you could limit it to as much or little CPU utilization as you want.
Plus, virtualizing is going to potentially require additional permissions that users may not want to grant your game (or may not be available on the platform).
That sounds kinda interesting/fun.
FWIW, given that you're running a game, and most people run games fullscreen, without anything else going, you can probably get away with not using virtualization, aka eating 100% CPU (or at least 100% of one core)... and even then, with most systems having >4 cores nowadays, you probably needn't worry at all.
But just to clarify the corollary, this implementation is running at around 250kHz (!). You wouldn't viably run Linux like this in a practical context anytime soon.