[mythtv] [mythtv-commits] Ticket #2782: automatic simultaneous jobs scaling

[osma ahvenlampi]

On 12/9/06, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> On 12/08/2006 02:29 AM, osma ahvenlampi wrote:
> > read idle time at all. I'll change it so that it will start *one*
> > process in either of those situations, but scale up from there only if
> > there's still time available. Would that be satisfactory?
>
> Yep.  With that change, I wouldn't even bother disabling the scaling.  I
> run with a max of 1 job on all my hosts because of the I/O issues that
> Daniel mentioned.  So, if it were allowed to start one job even at 0%
> idle (i.e. with 99% nice), it would be the same as I have currently.

This is what I just submitted to Trac, replacing the original jobqueue_2 patch.

> Perhaps a more "general-purpose" approach that would work for others,
> too, would be detecting the percentage of CPU time spent on idle plus
> the CPU time spent on processes running at a higher nice level than the
> job.  IIRC, jobs are run at nice 17, 10 or 0 depending on the value of
> JobQueueCPU, so any job running "nicer" than the nice setting for the
> job queue should be treated as idle time (i.e. time that could be used
> for the job queue).

It's not possible to detemine CPU used by individual nice levels
without going through the entire list of processes, which is not only
very complicated, requires a wee bit of CPU itself, but also suffers
from race conditions when processes come and go during the scan (look
at 'top' during 'make' -- CPU idle near 0%, yet no process seems to
use it - that's because the gcc that used it often just exited before
top got to see it).

Also, that's just on Linux. On some OSes I've seen, there's no way for
a user process to get to the information in the first place.

-- 
Osma Ahvenlampi   <oa at iki.fi>       http://www.fishpool.org