Boots and seems to work with PREEMPT enabled

[Anton Ivanov]

On 20/09/2023 13:30, Anton Ivanov wrote:
>
>
> On 20/09/2023 12:14, Anton Ivanov wrote:
>> Added support for kernel side fpu store/restore and real 
>> kernel_fpu_begin/kernel_fpu_end using gcc intrinsics. Enabled PREEMPT.
>>
>> It boots and seems to be alive and kicking. I do not notice any 
>> significant effect on performance either.
>>
>
> I take my words back - I was testing with VOLUNTARY which seems to 
> provide a difference withing the margin of error.
>
> Enabling forced preemption drops the time for
>
> find /usr -type f -exec cat {} > /dev/null \;
>
> from
>
> real    19m11.207s
> user    0m0.180s
> sys    2m41.160s
>
> to
>
> real    3m13.647s
> user    0m0.000s
> sys    2m58.270s
>
> And boot time from 11.5s to 6s.
>
> It did complain on shutdown though with some traces. Nothing while 
> running.

This is fixed by adding a preempt_enable/disable around the interrupt 
low level. We were quite obviously missing it.

>
> The patch will hit the mailing list shortly.

I will revise the patch and address the bug report on the config.debug.

>
>
>> How do I test it from here onwards?
>
> The question still stands. Can we use anything as a specific test 
> suite? It is not an area I am familiar with, so any pointers will be 
> welcome.
>
>>
>> I am happy to throw the patches on the list as an RFC, though I would 
>> prefer to test first :)
>>
>
However, this is about as much preemption as we can enable.

Trying to do what is suggested by Peter Zijlstra in the main PREMPT mail 
thread on LKM does not work for UML. At all.

His suggestion is to add preempt_schedule_irq() in the IRQ exit code. On 
UML that code is mixed with host signal handling and you cannot do that, 
because the irq_enable/disable in that function touch the signal mask. 
This makes a hash of the signal handling. In addition to that, we have 
missing preempt_enable/disable and/or guards around this part. It has 
some historical level of "reinvocation" and "reentrancy" behaviour and 
it gets in the way. That will need to be untangled, fixed to match 
preempt semantics and made to work. I'll be honest - I have no clue how 
long this will take.

My suggestion is that we take the rest with relevant fpu register 
store/restore fixes and the improvements it provides and leave the 
preempt_schedule_irq() part for later.

-- 
Anton R. Ivanov
https://www.kot-begemot.co.uk/