On 30 Mar 2001, at 15:53, [EMAIL PROTECTED] wrote:
> I run Mlucas on several Sparcs under Solaris at work,
> and I've noticed something not so nice about the Solaris
> nice command.
I never did find out why the (unix) command was called "nice". My
theory is that a neolithic unix hacker wanted to show off the latest
tool he'd written, but couldn't think of a name for. On being shown
the action of this tool, his colleague murmured "nice"!
Should the Solaris "nice" command should be renamed "ugly"?
> The lowest priority Solaris allows is 19,
I believe this is standard unix. It may be that linux et al are
diverging here.
> which on any other Unix-like OS I've used would mean the
> job in question only gets CPU cycles if no high-priority
> processes are running.
Well, that's what the documentation leads you to expect ... For
reasons like making sure that interactive processes are controllable
e.g. by mouse commands, there is always _some_ leakage of CPU cycles,
but the proportion needn't be anything other than very small.
> processes are running. However, under Solaris, something
> run at priority 19 still tends to get a
> not-insignificant share of CPU time - a typical number
> is 15% on a system with one other full-priority job
> running.
I sort of didn't really believe this until I checked it. But you're
right!
> This has caused me to have to restrict my GIMPS
> work to only our least-used (read: slowest) Sparcs,
> since people running actual work-related jobs don't
> want to be slowed down by a recreational-math program.
Sensible attitude ... doesn't bother me much on the two Solaris
systems I have access to, since the other jobs running tend to be I/O
bound rather than compute bound.
>
> So here's my question: does anyone know of a solution
> to the above conundrum? The first thing that came to my
> mind was to run the code as a cron job, but's that's not
> optimal since folks here tend to run jobs at any and all
> hours, often overnight.
Check out the Solaris priocntl command. I think you will find that
the default range of priority adjustment is 60 each way. With
priocntl you should be able to fix the Mlucas process so that it
adjusts much less - 10 each way should be enough. This will prevent
the scheduling priority rising enough so that anyone who has another
compute-bound process is losing a signficant number of CPU cycles.
You may also want to use ls -ful <username> to see the way in which
the scheduling priority, the nice value and the processor share are
correlated. (You might want to try this on a near-empty system with
another CPU soak program running un-niced in the foreground to
simulate the loading imposed by real users.)
I haven't actually tried this & may be wrong, but even if I have the
details wrong there's probably some way of using priocntl to throttle
a process so that it doesn't steal a significant number of CPU cycles
on a compute-bound system.
>
> What I'm thinking of is inspired by the output of the
> top utility - this lists (among other things) the
> average job load of a system, and also what % of the
> CPU time each active process is getting. (Since top is
> available for Sparc Linux, that means source code is
> available.) Would it be possible to write a script to
> basically emulate the OS's process scheduler, but which
> is used to control just one application? What I'd like
> this personal scheduler to do is the following:
I think it would be possible, but it may be unneccessary.
>
> 1) Every few seconds get the average system load, in
> terms of how many CPUs would be required to run every
> active process at full speed;
>
> 2) If the load exceeds the available number of CPUs,
> suspend the user program, but keep everything in main
> memory; otherwise, keep running.
Oops, this is _silly_. If you run a compute-bound process on an
otherwise totally unloaded system, the load average will be 1.0. So
your algorithm will thrash the process up & down.
I think the load average limit for starting the process should be
about one half less than the number of processors - say 0.5 on a
uniprocessor system - and the load average limit for stopping it
should be a little less than one more than the number of processors -
say 1.8 on a uniprocessor system.
The induced hysteresis will prevent the controlled process thrashing
up & down yet still force it out of the way when something else wants
to use the CPU capacity in a serious way.
>
> Any such scheme, in order to be practical, would have
> to be executable without superuser privileges.
Shouldn't be a problem. Start the script by looking for the Mlucas
process id. Then, in a loop: sleep for n seconds; check if the
process still exists (exit if not); check the load average; restart
or suspend as neccessary; repeat until hell freezes over. Run the
script as a detatched process using nohup &; it can safely run at
normal nice/priority since its resource usage will be minimal.
Ordinary users are (normally) allowed to control their own processes
(within reason), so I don't see that root privelege should be
required.
Regards
Brian Beesley
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
