[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Minios-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.