This is an additional patch on top of my previous design for workerpool priorities.
Signed-off-by: Michael Hanselmann <[email protected]> --- doc/design-2.3.rst | 39 +++++++++++++++++++++++++++++++++++++-- 1 files changed, 37 insertions(+), 2 deletions(-) diff --git a/doc/design-2.3.rst b/doc/design-2.3.rst index 71a9d4d..3e318c4 100644 --- a/doc/design-2.3.rst +++ b/doc/design-2.3.rst @@ -26,12 +26,47 @@ Job priorities Current state and shortcomings ++++++++++++++++++++++++++++++ -.. TODO: Describe current situation +Currently all jobs have the same priority. When a job is finished, the +next job is selected strictly by its incoming order. This does not mean +jobs are run in their incoming orderâlocks and other delays can cause +them to be stalled for some time. + +In some situations, e.g. an emergency instance shutdown, one may want to +run a job as soon as possible. This is not possible currently if there +are pending jobs in the queue. Proposed changes ++++++++++++++++ -.. TODO: Describe changes to job queue and potentially client programs +Each job will be assigned a priority on submission. Job priorities are +integers and the lower the number, the higher a job's priority +is. Jobs with the same priority are processed in submission order. +Submitted jobs can have one of the following priorities: + + - High (10) + - Normal (20, default) + - Low (30) + +The current LUXI call for job submission (``SubmitJob``) can not support +optional parameters. Therefore to not break existing clients, a new call +named ``SubmitJob2`` will be added. This will allow older clients to +continue to work without changes (e.g. htools). Jobs submitted using the +old call will get the default priority. + +Instead of looping when a job can't get its locks, the job will defer +itself with its priority decreased by one. This gives jobs with a higher +priority a chance to run (e.g. when all other worker threads are busy). +Otherwise the same job will be selected again right away by the worker +pool, which is equivalent to looping. Defered jobs stay in the +"waitlock" status. + +.. TODO: Should they go back to "queued"? + +Whether opcodes should still try to acquire their locks in blocking mode +after about 150 seconds of total waiting time needs to be investigated. + +Job priorities are synchronized to disk in order to be restored after a +restart or crash of the master daemon. Worker pool ^^^^^^^^^^^ -- 1.7.0.4
