What to do when two demos-sched instances are executed simultaneously?

[wentasah]

Options:

• nothing (current state)
• allow only one instance, others will fail
• something else?

[MatejKafka]

I think that except for interference between the instances (which we cannot really do anything about), it should be quite simple to support multiple instances of demos just by suffixing the root cgroup name with an index/UUID to avoid naming collisions, no? So if it would be deemed useful, it should be just few hours of work to implement it.

[wentasah]

Yes, it might be useful. But don't use UUID. Using the PID of demos-sched itself should be sufficient.

[MatejKafka]

For the CPU frequency scaling I'm currently working on, I don't think we can reasonably run it in multiple instances at once, as cpufreq is global for the whole system. Only reasonable solution I can think of would be to create a lockfile or a shared mutex whenever a demos instance takes control over power management, and delete it on exit. Any other instance would first attempt to create the lock and in case it already exists, run without active power management.

[wentasah]

Locking is a good solution. I prefer shared mutex/semaphore over the lock file. The lock file can be stored in a network filesystem, which is potentially shared between multiple boards, which would be problematic. Shared mutex/semaphore lives always in the same kernel as the cpufreq subsystem, which is what's needed.

[MatejKafka]

Cgroup name collision will be solved by suffixing the scheduler PID to cgroup name.

For power management, I originally wanted to do locking, but with #48, instances of DEmOS won't use power management by default, so I think it is (at least for now) ok to not detect other running instances using a lockfile, and instead make it the users responsibility to only enable power management if he's running a single instance.

Using a lockfile may still be useful to provide better warnings and not break configured governor with multiple instances running, but I don't consider it a high priority with #48.

[wentasah]

Agreed.

Maybe, it would make sense to print a warning, if demos is supposed to control CPU frequencies and the governor is set to userspace. In most cases, userspace governor is not the default, so if demos encounters this, it would mean that either another instance of demos or some other userspace cpufreq manager is running.

[wentasah]

Commit b0e6dc28499192a1eef873b0fff2553d34d3eab4 breaks running of demos without root. Demos then prints useless messages like this:

Cannot create necessary cgroups. Run demos-sched as root or run the following commands:
sudo mkdir /sys/fs/cgroup/freezer//demos-2066575
sudo chown -R 1000 /sys/fs/cgroup/freezer//demos-2066575
sudo mkdir /sys/fs/cgroup/cpuset//demos-2066575
sudo chown -R 1000 /sys/fs/cgroup/cpuset//demos-2066575

The name of the top-level group should stay the same. Perhaps, this issue should be solved together with unified cgroup hierarchy support (I'll create a separate issue for this).

[MatejKafka]

I know - for now, a working solution is to explicitly set the root cgroup name with -g (then the commands work again), but I agree it's not a good UX.