Today, it's far more common to run into limitations of disk I/O than it is to run into processor I/O limitations. From time to time, I have apps that need to take place, but at their own time schedule, and preferably without slowing the experience for interactive users.
If I recall properly, I made a request some time ago to the OpenBSD mail list due to using a disk-to-disk backup to a slow writing flash storage medium. I didn't care if the task took seconds or half an hour, I did care if I felt the system run slowly becasue of it. Ted Unangst took it as a challenge and rather quickly showed this bit of code on this thread.
It may not be perfect disk scheduling, but it solved my problem very nicely.
======================================================== #include <sys/types.h> #include <sys/wait.h> #include <signal.h> #include <stdlib.h> #include <unistd.h> #include <err.h> int main(int argc, char **argv) { int i; char **nargv; pid_t pid; int status; const int onesec = 1000000; nargv = malloc((sizeof(*nargv) * argc + 1)); for (i = 1; i < argc; i++) { nargv[i-1] = argv[i]; } nargv[i-1] = NULL; pid = fork(); if (pid == -1) err(127, "fork"); if (!pid) { execvp(nargv[0], nargv); write(2, "failed to exec\n", 15); _exit(127); } usleep(10); while (!waitpid(pid, &status, WNOHANG)) { kill(pid, SIGSTOP); usleep(onesec / 2); kill(pid, SIGCONT); usleep(onesec / 10); } return WEXITSTATUS(status); } ========================================================
Simple, but Works For Me.
Technically, this isn't actually throttling just disk activity, but ALL
activity of a program. The fact that it throttles disk I/O is just a
happy effect of the program.
Holland Consulting home
page
Contact Holland Consulting
since June 20, 2021
Page Copyright 2020, Nick Holland, Holland Consulting. Code stolen from others.