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/


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um

Reply via email to