Enhancement: SSD_SCHEDULER env variable for start-stop-daemon

[Forza-tng]

I think we should have the env variable SSD_SCHEDULER, similar to SSD_IONICELEVEL and SSD_NICELEVEL.

It is currently possible to use start_stop_daemon_args="--scheduler xxxx, but it would be more coherent to use the SSD_ style variable.

I'm currently involved with a new init.d script for a service that is very IO heavy, and letting users select idle or batch via conf.d would be great. Implementing the env variable would be much better than a service-specific option.

[FoxieFlakey]

(found this while Googling stuffs relating to this)

A little correction if its ok, don't you mean..

1. SSD_IOSCHEDULER and --ionice option if you meant I/O because batch is a process scheduler but you explained I/O

   -I, --ionice <arg>                Set an ionice class:data when starting

2. SSD_CPUSCHEDULER and --scheduler option because batch is one of CPU/process schedulers

     --scheduler <arg>             Set process scheduler

Note: Help information is from start-stop-daemon OpenRC version 0.53

[Forza-tng]

Thanks for your comments. I meant, as you guessed, CPU scheduler and not IO scheduler. It is possible to use --scheduler, but I do not think there is a corresponding ENV variable for it. SSD_CPUSCHEDULER would be a good name.

Perhaps something like this inserted at row 381?

// Handle SSD_CPUSCHEDULER for scheduler type
if ((tmp = getenv("SSD_CPUSCHEDULER"))) {
    scheduler = strdup(tmp); 
}

// Handle SSD_CPUSCHEDULER_PRIO for scheduler priority
if ((tmp = getenv("SSD_CPUSCHEDULER_PRIO"))) {
    if (sscanf(tmp, "%d", &sched_prio) != 1) {
        eerror("%s: invalid scheduler priority `%s' (SSD_CPUSCHEDULER_PRIO)",
                    applet, tmp);
    }
}

Testing it..

# SSD_CPUSCHEDULER="batch" start-stop-daemon  ls
Manifest  files  metadata.xml  openrc-0.53.ebuild

# SSD_CPUSCHEDULER="foobar" start-stop-daemon  ls
 * Unknown scheduler: foobar
 * start-stop-daemon: failed to start `ls'

[FoxieFlakey]

Yes and I suggest that more specific SSD_CPUSCHEDULER_PRIO override the SSD_NICELEVEL or warn the user that both is defined in environment as niceness level is used to calculate priority by the kernel.

[Forza-tng]

If I'm not mistaken, SCHED_OTHER/NORMAL, SCHED_BATCH and SCHED_IDLE uses niceness and ignores priority, while SCHED_FIFO and SCHED_RR uses priority and ignores niceness.

While SSD could make users aware of this by printing a warning, little else is gained by hard coding checks. What if the kernel adds or changes schedulers and we have hardcoded these options?

https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html