Re: [PATCH 07/13] rv: Simply hybrid automata monitors's clock variables

[Nam Cao <namcao@linutronix.de>]

Gabriele Monaco <gmonaco@redhat.com> writes:
> Well, this is roughly what we discussed in [1].
> Now, I didn't submit the throttle monitor yet because it depends on unacked
> tracepoints.

Thanks for bringing that up. I had no memory of that discussion.

> In short, this works with the assumption that the expires value you pass to
> ha_check_invariant() is the same you used to arm the timer.
>
> That's true for constant values only (the deadline) but not for something like
> the runtime. I couldn't think of a way to rearrange that model not to require
> the runtime left field.

I believe you are referring to this:

                                     |
                                     |
      dl_replenish;reset(clk)        v
              sched_switch_in   #=========================# sched_switch_in;
               +--------------- H                         H   reset(clk)
               |                H                         H <----------------+
               +--------------> H         running         H                  |
    dl_throttle;reset(clk)      H clk < runtime_left_ns() H                  |
   +--------------------------- H                         H sched_switch_out |
   |       +------------------> H                         H -------------+   |
   | dl_replenish;reset(clk)    #=========================#              |   |
   |       |                         |             ^                     |   |
   v       |                  dl_defer_arm         |                     |   |

Now that I stared at this again, I think we already deviate from theory
here. Our documentation mentions that the invariant must be in the form

        g = v < c | true

with "c [being] a numerical value".

The invariant "clk < runtime_left_ns()" means clk must not exceed the
remaining runtime, which is sampled by calling runtime_left_ns() when
the state is entered. This is not in the theory. Additionally, I think
this interpretation is ambiguous; one could also interpret that as "the
clk value must never exceed the *current* value returned by
runtime_left_ns()".

I digged into the cited academic papers, but couldn't find anything that
can describe this. The closest I see is the "init" label for states, but
that is the condition for entering the states.

> Otherwise.. We could read the remaining time in the timer, but we wouldn't be
> able to simulate ns precision when using the timer wheel.
>
> Now if we really wanted to go down that path, we are using a union to allocate
> either timer or hrtimer, the latter is larger, so we /could/ add a u64 expire_ns
> field to the ha_monitor struct without needing additional memory.
>
> If that doesn't sound too wild to you, I may try and sketch something up to see
> if that's viable. Then this patch could go through as is and I would add the
> extension together with the submission of throttle.

That can work, but not ideal, because hrtimer will not be usable.

Looking at the throttle monitor again, is it possible to rewrite
runtime_left_ns() to read .dl_runtime instead of .runtime? I don't know
the deadline schedule very well, but I think .dl_runtime is not changing
like .runtime?

Nam