Consider creation of "rest of the system" partition

[wentasah]

This partition would "swallow" all other processes existing in the system at the time of starting DEmOS. This might be useful to limit the interference from non-DEmOS (e.g. system) processes.

Things to consider/investigate:

• what to do with systemd and its services?
• only one demos scheduler can create such a partition.

[MatejKafka]

Another issue - if running demos on a remote system, it means that the SSH connection & shell will be unresponsive except when "rest of the system" partition is active, so output created when other partitions are running would not be visible (and we're risking an IO block when the buffers are not flushed for some time). I'd assume there will be other similar issues for different scenarios.

To make this work in a reasonably user-friendly way, we'd probably have to support some way to whitelist (exclude) given processes. Another solution could be to reserve one CPU core for the system partition, which would allow the rest of the system to always run on at least one core, which should be enough to keep a typical non-GUI system responsive, at the cost of reduced performance for demos.

[wentasah]

Doing whitelists/blacklists is a way to hell. There will always be something missing. I think that for now, we can ignore this issue and say that it's administrator's responsibility to limit the effect of other processes.

[MatejKafka]

I meant a way for a user to write his own whitelist/blacklist, probably in the config file, but I agree it's not a great solution either way.

[wentasah]

If anything, it would be reasonable not to freeze the other processes, but only limit them with the CPU cgroup controller. But this wouldn't play nicely with systemd, which itself allows configuring CPU limits for system services. Better not to implement it now, until we understand what is exactly the problem we're solving (if any).