Re: [Minios-devel] [UNIKRAFT PATCH v2] plat/*: Configure timer interrupt frequency

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hey Costin, hey Florian,

On 05.10.2018 11:39, Costin Lupu wrote:
> On 10/5/18 12:24 PM, Florian Schmidt wrote:
> > Hi Costin,
> >
> > let me give a quick answer:
> >
> > On 10/02/2018 09:16 AM, Costin Lupu wrote:
> > > I find allowing users the freedom to set any frequency they like to have
> > > 2 disadvantages:
> > >
> > > 1. The tick frequency should be chosen based on a prior analysis
> > > depending on the application. An integer field would allow users to set
> > > any frequency they want whether they know what they're doing or not. I
> > > find this level of freedom dangerous here.
> > Well, that's up to the developer, I think. I'm for the freedom to shoot
> > yourself in the foot if you think you know better what to set here.
> >
> >
> > > 2. A given frequency value may not be supported by the underlying timers
> > > and therefore it would either have no effect (e.g. being ignored) or
> > > generate an incorrect behavior.
> > That should be captured by an error-handling mechanism, right? Through a
> > CRIT warning or worst case crash when a settings doesn't work. Or are
> > you saying that some timers silently ignore unsupported settings without
> > giving any way to figure out whether a setting will work or not?
> In deed, an error handling mechanism should be introduced in this case.
> But this would only add more complexity and should be according to each
> supported timer. Please keep in mind that there is no standard way of
> configuring timers and the set of accepted interrupt frequency values
> may differ.
I agree with Florian that this should be more flexible to configure 
(e.g., with an integer value range). What are the limitations that you 
see? Are they really so different among the platforms and architectures 
that we support (Linux, Xen, KVM, x86, Arm)?
Assuming that we can find a set of possible frequency values, I even 
think that the person that builds a Unikernel should set up the 
frequency within the selected scheduler library. A particular scheduler 
algorithm should give you a much better idea which frequencies are 
meaningful to configure.
To make this possible, there should be a platform API to let the 
scheduler set up the frequency during its initialization. This would 
also remove the expensive timer ticks on Unikernels that use no 
scheduling at all or use the cooperative scheduler. Of course, the error 
check code is anyways required for this case.
In the future, we should even think about supporting dynamic ticks. A 
scheduler library may want to dynamically size each time slices or may 
want to temporarily switch off any ticks if there is nothing to do. 
Imagine that you run hundreds or thousands of Unikernels on a single CPU 
core. Having the timer frequency statically set for all of them will 
make the CPU unnecessarily busy with handling these ticks only. So, you 
anyway want to have a platform API where you can change the timer 
counter value for each iteration.
Since modern OSes support dynamic ticks, I think that there aren't too 
complicated restrictions on the platforms. Am I right?
> > > Now regarding the number of options, two should be enough for making the
> > > case for how we can configure the timer. Please feel free to amend this
> > > patch or to submit another one for extending the number of options.
> > I might do that, but I'd prefer to have some additional input from
> > others first.
> >
> > Cheers,
> > Florian
_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel