Hi Chris,

El 21.08.20 a las 22:04, Chris Hofer escribió:

Hi everyone,

I'm having some troubles in understanding how the concept of 'fills' and 'claims' of base-hw's scheduler [1] is expressed in the Xml syntax of Init's configuration.

My concrete questions are:

* how does the syntax indicate, whether the threads of a component are    treated as fills or claims?

Threads, fills and claims are three different things although they are connected to each other in some way.

Each thread (independent from any XML configuration) owns exactly one "fill". A "fill" is a contingent for the priority-less default round-robin mode of the scheduler. This mode is only active when there is nothing to be scheduled that would have priority. So, each thread participates in the "fill" scheduling of the scheduler as long as it is active and has not lent its "fill" to another thread. All "fills" are treated equally.

Besides that, each thread owns exactly one "claim". Each claim has a specific priority. That's the priority that results from the accumulated "prio_levels"/"priority" attributes along the way from Genodes Core to the component the thread runs in. For example in...

<config prio_levels="4"> ... <start name="init_1" priority="-1"> <binary name="init"/> <resource name="CPU" quantum="10"/> ... <config> ... <start name="app_1"> ... <resource name="CPU" quantum="50"/> </start>

</config> </start>

<start name="init_2" priority="-2" caps="1000"> <binary name="init"/> <resource name="CPU" quantum="80"/> ... <config prio_levels="2"> ... <start name="app_2" priority="-1"> ... <resource name="CPU" quantum="75"/> </start>

</config> </start> </config>

... the components (and therefore the claims of all their threads) end up with the following priorities:

init_1: 3 of 4 app_1: 3 of 4 init_2: 2 of 4 app_2: 1 of 4

A "claim" is the right to participate in the round-robin scheduling of the given priority level. Higher priority levels always precede lower levels and each priority level precedes the "fill" level mentioned at the beginning.

But claims have a limited charge denoted by the "quantum" attribute in the XML configuration. As soon as this charge is consumed, the "claim" becomes inactive (the thread might still be scheduled through its "fill"). But claims get re-charged to the quantum value regularly. This is the so-called superperiod, which is set to 1 second currently.

The quantum values in the XML configuration are percentages. These percentage numbers always refer to the quantum of the parent of the component and are donated from parent to child. That said, the components in the example end up with the following quantum values:

init_1: 0% of 1 second app_1: 5% of 1 second init_2: 20% of 1 second app_2: 60% of 1 second

A "claim" of a thread of a component with 0% quantum is always inactive. The corresponding thread is only scheduled through its "fill".

* do priorities affect the scheduling of fills?

No.

The background of the second question is, that I'm confused by the priority assignment in the run-script vmm_arm.run. I expected all components to be fills and scheduled in a round-robin fashion. What is the reason for assigning the priority -1 to the Vmm?

I'm not the author of this run script but a VMM is an execution-time demanding task and the run script also issues a timer and a NIC driver. These drivers normally require low latency scheduling. Therefore, the VMM should get tamed by putting it one priority level below the drivers.

BUT, in this specific run script, the CPU quantum values are missing for historical reasons. Therefore, at least on base-hw, the priorities are ineffective and all threads are only scheduled through their "fill". This should indeed be fixed.

I hope this helped!?

Cheers, Martin