| |||||||||||||
|
| |||||||||||||
XorgXorgPosted Mar 15, 2007 11:58 UTC (Thu) by jospoortvliet (subscriber, #33164)In reply to: Xorg by xav Parent article: RSDL hits a snag
well, 'fault' might not be the right word, but RSDL WILL be inherently
But the point is, I should nice them. The interactive schedulers,
Automatic niceing would be a good thing (eg gcc or make should nice
(Log in to post comments)
Xorg Posted Mar 15, 2007 12:10 UTC (Thu) by k8to (subscriber, #15413) [Link] I wonder if there is some clever way I can express niceness. Like "I would always like autofoo and libtool to run with nice at least 5" or some such. It's not too uncommon that a task I would think to nice manually when run directly is not always run directly, leaving me to renice moderately laboriously.
I guess I'm saying if we're going to push priority setting onto users for them to achieve pleasant interactivity then maybe there could be better tools for the priorities to be set?
I've personally always been extremely murky on what nice is supposed to do on Unix. Sometimes it doesn't seem to do much at all. My Amiga featured simplistic preemption, which was easy to grasp. The highest priorty task would run, priorities were fixed, and you could set them arbitrarily. The only sort of unexpected behavior you would get is if you set your cpu bound program to a higher priority than the (task-implemented) filesystem. Unix is certainly safer for the multi-user case, but I often find myself infurated that I can't prevent the "low priority" task from slowing down my "high priority" task.
VeryNice Posted Mar 15, 2007 12:27 UTC (Thu) by brugolsky (✭ supporter ✭, #28) [Link] See the VeryNice Dynamic Process Re-nicer.From the homepage: VeryNice is a tool for dynamically adjusting the nice-level of processes under UNIX-like operating systems. It can also be used to kill off runaway processes and increase the priority of multimedia applications, while properly handling both batch computation jobs and interactive applications with long periods of high CPU usage.
Xorg Posted Mar 15, 2007 16:55 UTC (Thu) by vmole (guest, #111) [Link] Like "I would always like autofoo and libtool to run with nice at least 5" or some such. Create file nice_5 in /usr/local/bin (or ~/bin): #!/bin/bash exec nice -5 "$@" Then create links in /usr/local/bin (or ~/bin): ln -s nice_5 gcc ln -s nice_5 libtool ln -s nice_5 autobarf Put /usr/local/bin (or, need I say, ~/bin) early in your path.
autobarf?? Posted Mar 15, 2007 21:58 UTC (Thu) by pr1268 (subscriber, #24648) [Link] Is autobarf a standard Unix/Linux shell program? I can't seem to find it on my Slackware system.
Xorg Posted Mar 16, 2007 2:46 UTC (Fri) by njs (subscriber, #40338) [Link] > exec nice -5 "$@"
I believe you mean:
exec nice -5 "$0" "$@"
Xorg Posted Mar 16, 2007 17:25 UTC (Fri) by vmole (guest, #111) [Link] Oops. You're absolutely correct. Sorry about that, to anyone trying this at home.
Xorg Posted Mar 27, 2007 23:29 UTC (Tue) by efexis (guest, #26355) [Link] Only if you want a script which perpetually exec's itself... otherwise, you'll need to put the absolute path in to the original binary it's meant to be calling, or drop the location of the script from the PATH env.
eg, for background running tasks, such as make:
Xorg Posted Mar 16, 2007 15:17 UTC (Fri) by k8to (subscriber, #15413) [Link] Yeah i'm currently using such a trick to run i386 binaries, and another similar trick for a special file database maintenance task. I'm kind of uneasy with them in terms of unexpected complexity springing out at the user in the troubleshooting case.
Xorg Posted Mar 23, 2007 15:57 UTC (Fri) by slamb (guest, #1070) [Link] I think it'd need to be a bit more clever than that - the shell doesn't replace $PATH, so this will just exec itself over and over. You'll need to either specify a more limited path or manually walk $PATH, excluding symlinks to itself.
what nice means Posted Mar 17, 2007 2:59 UTC (Sat) by giraffedata (subscriber, #1954) [Link] I've personally always been extremely murky on what nice is supposed to do on Unix. Sometimes it doesn't seem to do much at all. The last time I investigated that was years ago, so who knows what nice is now, but assuming it's roughly the same: Nice is just a limit on the priority a process is allowed to have, as the scheduler adjusts it up and down according to its own policies. If the scheduler naturally comes to the same conclusion as you as to the needs of a process, your nice won't have an effect. You can watch priorities in 'top' (better: 'htop') and get an idea. For me, the big compile job I force to be nice is often pretty nice anyway just because the scheduler figures out it's a long running job. And the priority value itself is no great thing: it's just how long the process is allowed to keep the CPU when it gets it. Even the highest priority process can wait a long time to get it.
My Amiga featured simplistic preemption, which was easy to grasp. The highest priorty task would run, priorities were fixed, and you could set them arbitrarily. This is all just the dynamic priority scheme, i.e. scheduling among processes with absolute priority 0 (which is usually all of them). If you give a process absolute priority 1, it will always run before any of the processes with absolute priority 0; it can even preempt a process that already has it. (Absolute priorities are what people usually call realtime priority).
|
|
||||||||||||