Antoine Durr wrote:
> So I whipped up something this afternoon. It's pretty simplistic, and
> I'm curious as to where it might fall flat on its nose.
You might find that 'beats up' rush too much by having it change
things every 5 seconds.
Also, try to avoid running 'rush -cp' commands if it's not actually
changing anything.
The script I'm writing counts the number of available cpus,
and splits them up to each user. So if there are 15 procs
and 3 different users, each user gets 5 cpus assigned to their
jobs. If a user has multiple jobs, each job gets a few cpus,
but no more than 5 total for all their jobs.
I'm getting hung up on the latter condition of what to do
when a user has 10 jobs with all their priorities equal,
but only 5 cpus allocated to them; just assign 1 cpu to
their first 5 jobs, and let the others languish until
more procs free up or jobs finish?
I'm using 'rush -status +any -c 0 -s 20' to get the job info;
it will poll forever until killed, and is low bandwidth.
I'm caching the data, looking for changes in job states
or jobs either added or removed.
I count 'available cpus' as cpus that are 'online' and
don't have RESERVE jobs assigned to them.
Anyway, it's taking a while to write, to handle the weird
situations.
But definitely you must avoid the tendency to keep changing
things in rush to the point where all it's doing is rescheduling
things. Only tell rush to change things when there's something
worth changing, and try not to 'oscillate' (ie. jumping jobs
up and down one or two procs every iteration, due to rounding)
--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|