Thanks, answers inline. On Thursday, August 25, 2016 at 2:20:20 PM UTC+1, Klaus Aehlig wrote: > > [...] > > +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) >
Yes, I had considered this as well and I wasn't sure if it would be beneficial or not. I don't think it changes much but it's probably better to have a definite range of values than dipping into the negative numbers infinitely. > > +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). > Actually some RUNNING jobs end up releasing locks while they are executing :) But that's a good thing so it doesn't matter. We could also read the state of the WAITING jobs and if so, go back to the normal declarative lock approach (just like we do for the pending jobs). This is mostly just an implementation detail, but thanks for pointing it out as it will be taken in consideration. > - 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). > Again thanks for pointing out a possible pitfall, I'll keep that in mind. > > 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 >
