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

[Costin Lupu <costin.lup@xxxxxxxxx>]

Hi Simon,

I created this patch because I needed a way to read the timer tick (1)
when setting the time slice for a thread and (2) when preempting
threads. I can simply get rid of the configuration options and define
the frequency and tick values depending on the platform and keeping the
old behavior. This would seem like the simpler solution here and just
extend the functionality when such thing would be needed.

Regarding your comments, please see my comments inline.

On 10/8/18 12:49 PM, Simon Kuenzer wrote:
> 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)?
> 

I'm not sure what you mean here by being more flexible. Choosing any
integer value from an interval? Can you please give an example of such
system?

> 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.

You mean moving the configuration entry in a scheduler implementation
library menu?

> 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.

When you say "to let the scheduler set up the frequency" you mean:
1. enabling the timer interrupt and setting a frequency, or
2. just setting a frequency for the timer interrupt ?

I'm asking this because it's not clear to me whether the scheduler can
later reconfigure the frequency in this scenario.

> 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.

Florian just commented that we should have the frequency set statically.
So which one should it be?

> Since modern OSes support dynamic ticks, I think that there aren't too
> complicated restrictions on the platforms. Am I right?
> 

I'm not sure what you mean by "too complicated restrictions" here.

>>
>>>
>>>> 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