Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: SSD_SCHEDULER env variable for start-stop-daemon #657

Open
Forza-tng opened this issue Oct 8, 2023 · 4 comments · May be fixed by #693
Open

Enhancement: SSD_SCHEDULER env variable for start-stop-daemon #657

Forza-tng opened this issue Oct 8, 2023 · 4 comments · May be fixed by #693

Comments

@Forza-tng
Copy link
Contributor

Forza-tng commented Oct 8, 2023

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.

@Forza-tng Forza-tng changed the title Enhancement: SSD_SHEDULER env variable for start-stop-daemon Enhancement: SSD_SCHEDULER env variable for start-stop-daemon Oct 8, 2023
@FoxieFlakey
Copy link

(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
  1. 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
Copy link
Contributor Author

Forza-tng commented Feb 21, 2024

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
Copy link

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants