Base-hw scheduler

[Martin Stein]

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