[systemd-devel] Reason for setting runqueue to IDLE priority and side effects if this is changed?

[Lennart Poettering]

On Wed, 15.07.15 17:30, Hoyer, Marko (ADITG/SW2) (mhoyer at de.adit-jv.com) wrote:

> Systemd v211 added the running queue as deferred event source to the
> event handling with priority IDLE. So dbus requests are preferred
> over job execution. The reverse order effect is simply because the
> run queue is more a stack than a queue. All of the observed behavior
> could be explained I guess.
>
> So long story in advance. I've now two questions:

> - Am I causing any critical side effects when I'm increasing the run
>   queue priority so that it is higher than the one of the dbus 
>   handling (which is NORMAL)? First tests showed that I can get back
>   exactly the behavior we had before with that.

The idea was that if the user wants us to undo some operation, we
better operate on that first, before we execute the job he might want
to undo. Hence dbus requests get priority. But other than that I don't
see how this would be a problem.

> - Might it still happen that situations are happening where the jobs
>   are reordered even though I'm increasing the priority?

Well, we currently say that the order in which jobs are dispatched if
multiple are runnable (where "runnable" means "all deps satisfied") is
undefined.

I'd be willing to add a new unit setting to unit files that would
allow altering the order in which jobs are dispatched if multiple are
runnable. For example, we could add a new value Priority= which could
allow altering the order in which runnable jobs are dispatched. This
run queue (which is actually a stack right now...) would then become a
priority queue. Such a ptahc would probably not be too difficult,
given that we already have a prioq abstract data structure in systemd.

> - Is there any other good solution ensuring the order of job execution?

No yet, sorry. Would be happy to take a patch implementing what I
suggested above!

Lennart

-- 
Lennart Poettering, Red Hat