Re: disknice
Hi Ted,
> 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);
The basic idea - only giving part of the system resources to the
maintenance job - looks nice, but even after polishing a few details
and doing some integration, i wonder whether the SIGSTOP/SIGCONT
approach is good enough as the standard solution to be included
in base.
For example, i wonder whether on some fast hardware, 100ms of load
might be sufficient to drain a buffer required to burn a CD/DVD?
Or whether 100ms of load every 500ms might be noticeable on some
hardware when watching a video stream or listening to music?
Admittedly i'm just whining. I have no idea how to implement
real priorities for disk IO. So i shall shut up now.
Yours,
Ingo
Re: disknice
On Thu, Feb 4, 2010 at 5:44 PM, Ted Unangst wrote:
> I haven't really solved the problem I want to solve, but was able to whip
> this up pretty quickly. Basically, it's just a wrapper that runs a
> command and then starves it from running. disknice is a misnomer, it also
> gets starved from cpu, but at the current time the only way to slow down a
> process's io is to stop it. Not a complete solution, but it will slow
> down a large tar job to the point where other programs have plenty of time
> to get their requests in. The sleep ratios should be tunable, aren't.
>
>
>> time disknice md5 -t
> MD5 time trial. Processing 1 1-byte blocks...
> Digest = 52e5f9c9e6f656f3e1800dfa5579d089
> Time = 3.339803 seconds
> Speed = 29941885.793863 bytes/second
>0m3.50s real 0m0.30s user 0m0.00s system
>
>
> #include
> #include
>
> #include
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
>int i;
>char **nargv;
>pid_t pid;
>int status;
>const int onesec = 100;
>
>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);
> }
>
>
May I suggest this diff:
--- disknice.c.orig Fri Feb 05 10:02:49 2010
+++ disknice.c Fri Feb 05 10:03:32 2010
@@ -13,13 +13,9 @@
pid_t pid;
int status;
const int onesec = 100;
-
- nargv = malloc((sizeof(*nargv) * argc + 1));
- for (i = 1; i < argc; i++) {
- nargv[i-1] = argv[i];
- }
- nargv[i-1] = NULL;
-
+
+ nargv=&argv[1];
+
pid = fork();
if (pid == -1)
err(127, "fork");
I think those lines represent a rather inefficient way of doing that,
not to mention a memory leak. You get the same effect by shifting
argv along by one, without having to dabble in allocating memory and
the like.
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: disknice
2010/2/4 Ted Unangst :
> I haven't really solved the problem I want to solve, but was able to whip
> this up pretty quickly. Basically, it's just a wrapper that runs a
> command and then starves it from running. disknice is a misnomer, it also
> gets starved from cpu, but at the current time the only way to slow down a
> process's io is to stop it. Not a complete solution, but it will slow
> down a large tar job to the point where other programs have plenty of time
> to get their requests in. The sleep ratios should be tunable, aren't.
>
>
>> time disknice md5 -t
> MD5 time trial. Processing 1 1-byte blocks...
> Digest = 52e5f9c9e6f656f3e1800dfa5579d089
> Time = 3.339803 seconds
> Speed = 29941885.793863 bytes/second
>0m3.50s real 0m0.30s user 0m0.00s system
>
>
> #include
> #include
>
> #include
> #include
> #include
>
> int
> main(int argc, char **argv)
> {
>int i;
>char **nargv;
>pid_t pid;
>int status;
>const int onesec = 100;
>
>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);
> }
>
>
I really like this idea, is there any way we could watch how much IO a
process is doing ?
We could then decide to SIGSTOP it, I know it's still not a solution
but I could use that.
Re: disknice
On Thu, Feb 04, 2010 at 01:20:32PM +0100, Bret S. Lambert wrote: > On Thu, Feb 04, 2010 at 06:59:36AM -0500, Kenneth R Westerback wrote: > > On Thu, Feb 04, 2010 at 01:59:18AM -0500, STeve Andre' wrote: > > > On Thursday 04 February 2010 01:44:15 Ted Unangst wrote: > > > > I haven't really solved the problem I want to solve, but was able to > > > > whip > > > > this up pretty quickly. Basically, it's just a wrapper that runs a > > > > command and then starves it from running. disknice is a misnomer, it > > > > also > > > > gets starved from cpu, but at the current time the only way to slow > > > > down a > > > > process's io is to stop it. Not a complete solution, but it will slow > > > > down a large tar job to the point where other programs have plenty of > > > > time > > > > to get their requests in. The sleep ratios should be tunable, aren't. > > > > > > > > > time disknice md5 -t > > > > > > I'm definitely going to play with this. > > > > > > To retard a process might be a better word, but might raise objections, > > > so arrest, bridle or moderate might be better? > > > > > > --STeve Andre' > > > > 'filibuster' the process? > > 'healthily debate' the process, if you're in the US > > > > > Ken > > ^C == cloture Ken
Re: disknice
On Thu, Feb 04, 2010 at 06:59:36AM -0500, Kenneth R Westerback wrote: > On Thu, Feb 04, 2010 at 01:59:18AM -0500, STeve Andre' wrote: > > On Thursday 04 February 2010 01:44:15 Ted Unangst wrote: > > > I haven't really solved the problem I want to solve, but was able to whip > > > this up pretty quickly. Basically, it's just a wrapper that runs a > > > command and then starves it from running. disknice is a misnomer, it also > > > gets starved from cpu, but at the current time the only way to slow down a > > > process's io is to stop it. Not a complete solution, but it will slow > > > down a large tar job to the point where other programs have plenty of time > > > to get their requests in. The sleep ratios should be tunable, aren't. > > > > > > > time disknice md5 -t > > > > I'm definitely going to play with this. > > > > To retard a process might be a better word, but might raise objections, > > so arrest, bridle or moderate might be better? > > > > --STeve Andre' > > 'filibuster' the process? 'healthily debate' the process, if you're in the US > > Ken
Re: disknice
On Thu, Feb 04, 2010 at 01:59:18AM -0500, STeve Andre' wrote: > On Thursday 04 February 2010 01:44:15 Ted Unangst wrote: > > I haven't really solved the problem I want to solve, but was able to whip > > this up pretty quickly. Basically, it's just a wrapper that runs a > > command and then starves it from running. disknice is a misnomer, it also > > gets starved from cpu, but at the current time the only way to slow down a > > process's io is to stop it. Not a complete solution, but it will slow > > down a large tar job to the point where other programs have plenty of time > > to get their requests in. The sleep ratios should be tunable, aren't. > > > > > time disknice md5 -t > > I'm definitely going to play with this. > > To retard a process might be a better word, but might raise objections, > so arrest, bridle or moderate might be better? > > --STeve Andre' 'filibuster' the process? Ken
Re: disknice
On Thursday 04 February 2010 01:44:15 Ted Unangst wrote: > I haven't really solved the problem I want to solve, but was able to whip > this up pretty quickly. Basically, it's just a wrapper that runs a > command and then starves it from running. disknice is a misnomer, it also > gets starved from cpu, but at the current time the only way to slow down a > process's io is to stop it. Not a complete solution, but it will slow > down a large tar job to the point where other programs have plenty of time > to get their requests in. The sleep ratios should be tunable, aren't. > > > time disknice md5 -t I'm definitely going to play with this. To retard a process might be a better word, but might raise objections, so arrest, bridle or moderate might be better? --STeve Andre'
