[...]
> +something similar to, for example, 1 tick every 30 seconds. Using the current
> +formula, we can define the actual job weight in the queue::
> +
> + weight = spv(job)*(1 - job.Age()/K)
> +
Probably should read
weight = spv(job)*max(0, 1 - job.Age()/K)
> +Where spv(job) is the value obtained by the heuristic algorithm (Static
> +Predictive Value), Age is the given job's quantized age, and k is an aging
[...]
> +defined in the previous section). Luckily, for the currently running opcodes,
> +it is possible to query the system for the state of the locks and we can
> +achieve a more accurate map, which helps improving the accuracy of the
> +heuristic function.
Some care has to be taken when implementing the querying for live lock data.
- During waiting stage, mcpu ocassionally drops all locks and reaquires them,
to allow other jobs with fewer lock requirements to come inbetween. So for
job in WAITING, the answer depends on the timing of the question (truely
RUNNING jobs, don't drop their needed locks, of course).
- The information about held locks is available in wconfd (and on disk), whereas
the scheduling is done by luxid; so all the usual care with inter-process
communication has to be taken (including taking into account that wconfd might
be restarting at the moment).
But the design LGTM; however, a currently active Ganeti core member should
review
before submitting a new design.
Thanks,
Klaus
--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Matthew Scott Sucherman, Paul Terence Manicle
