Re: [UNIKRAFT PATCH] include: Introduce uk/preemmpt.h

[Simon Kuenzer <simon.kuenzer@xxxxxxxxx>]

Hi Costin,

fair enough. It makes sense what you say. With this in mind, I propose 
the following improvement for this header:
We distinguish with CONFIG_HAVE_SCHED if we need to do something 
regarding scheduling or not. This option indicates if the platform 
library is compiled with context switch capabilities.
For !CONFIG_HAVE_SCHED:
        We use only memory barriers.

For CONFIG_HAVE_SCHED:
	We do another check for CONFIG_LIBUKSCHED. If uksched is not there, we 
use interrupts on/off + memory barriers. For the case uksched is there, 
I expect that an API call in uksched is provided to do this nesting 
count and disable preemption (this will probably be mapped to a no-op 
for the cooperative scheduler and an actrual function to preemptive 
schedulers). The memory barrier should stay within the preempt.h header.
Of course a brief description should be in the header that says that 
this is not about irqs on/off but disabling thread context migration to 
different CPU cores and thread interruption.
We can put the check for CONFIG_LIBUKSCHED as a TODO for now, because I 
think preempted scheduling needs to be upstreamed first. So I would go 
for irq on/off for now. Later we will implement the uksched case properly.
All-in-all, I see this as a kind of a compromise, but we would cover all 
cases including a good enough support for non-uksched scheduling with 
irqs on/off (which may happen for robotics use cases).
What do you think?

Thanks,

Simon

On 23.07.20 17:59, Costin Lupu wrote:
> On 7/23/20 6:32 PM, Simon Kuenzer wrote:
> > Hey Costin, hey Alexander,
> >
> > a question from my side as clarification. I understand this is kind
> > of an adopted concept from Linux.
> Well, it's actually about critical sections which is an old systems
> concept. [1]
>
> > However, is it intended that interrupts do not count as preemption?
> > When do I use uk_preempt_disable() and when lcpu_irqf_save()?
> Disabling interrupts does disable preemption. However, here we need to
> disable only preemption in order to keep the current thread running on
> the current CPU. But the advantage here is we can also continue to
> handle interrupts.
>
> If for example the current thread is the ring consumer and the ring is
> filled in interrupt context then we must leave the interrupts enabled.
>
> > When scheduling is there, does this general header get a dependency
> > to uksched?
> That's right. More precisely, when preemptive scheduling is there.
>
> > In such a case, shouldn't this header go to uksched and in ukring we
> > include it as soon as uksched is selected?
> Well, not necessarily. In the ring implementation you just need to
> define critical sections. The ring implementation doesn't care whether
> there is a scheduler around or not. It just needs to make the calls that
> helps it define the critical sections. That's why I don't think it's
> necessary to directly link the ring with the scheduler.
>
> [1]
> https://en.wikipedia.org/wiki/Critical_section#Kernel-level_critical_sections
>
> Cheers,
> Costin