Re: Arches that don't support PREEMPT

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, Sep 19 2023 at 17:41, Anton Ivanov wrote:
> On 19/09/2023 17:22, Richard Weinberger wrote:
>> ----- Ursprüngliche Mail -----
>>> Von: "anton ivanov" <anton.ivanov@cambridgegreys.com>
>>> It's been a while. I remember that I dropped it at the time, but do not remember
>>> the full details.
>>>
>>> There was some stuff related to FP state and a few other issues I ran into while
>>> rewriting the interrupt controller. Some of it may be resolved by now as we are
>>> using host cpu flags, etc.
>> 
>> I remember also having a hacky but working version almost 10 years ago.
>> It was horrible slow because of the extra scheduler rounds.

Which can be completely avoided as the proposed change will have the
preemption points, but they are only utilized when preempt FULL is
enabled (at boot or runtime). So the behaviour can still be like preempt
NONE, but with a twist to get rid of the cond_resched()/might_resched()
and other heuristic approaches to prevent starvation by long running
functions. That twist needs the preemption points.

See https://lore.kernel.org/lkml/87cyyfxd4k.ffs@tglx

>> But yes, if PREEMPT will be a must-have feature we'll have to try again.
>
> We will need proper fpu primitives for starters that's for
> sure. fpu_star/end in UML are presently NOOP.
>
> Some of the default spinlocks and other stuff which we pick up from
> generic may need to change as well.
>
> This is off the top of my head and something which we can fix straight
> away. I will send some patches to the mailing list tomorrow or on Thu.

I think it does not have to be perfect. UM is far from perfect in
mimicing a real kernel. The main point is that it provides the preempt
counter in the first place and some minimal amount of preemption points
aside of those which come with the preempt_enable() machinery for free.

Thanks,

        tglx