Re: [RFC PATCH] arm64/fpsimd: Don't disable softirq when touching FPSIMD/SVE state

[Julien Grall]

Hi Sebastian,

On 3/4/19 5:25 PM, Sebastian Andrzej Siewior wrote:
> On 2019-02-18 15:07:51 [+0000], Julien Grall wrote:
> > Hi,
> Hi,
>
> > > Wouldn't this arbitrarily increase softirq latency?  Unconditionally
> > > forbidding SIMD in softirq might make more sense.  It depends on how
> > > important the use cases are...
>
> It would increase the softirq latency but the question is how bad would
> it be. It would continue once the SIMD section is done.

On Arm, the kernel may use either FPSIMD or SVE (if supported by the 
platform). While the FPSIMD context is fairly small (~4K), the SVE 
context can be up to ~64KB.

> If you allow it but made it impossible to use (and use the software
> fallback) then it would slow down the processing. Soâ

This is a fair point. However, the use of crypto in softirqs seem to be 
limited. So I am wondering whether disabling softirq in all the case is 
worth it.

Would it be possible to consider to forbid/warn about using crypto in 
softirqs?

> > Looking at the commit message from cb84d11e1625 "arm64: neon: Remove support
> > for nested or hardirq kernel-mode NEON", one of the use case for crypto in
> > softirq is certain mac80211 drivers.
> >
> > Is there any other use case for use crypto in softirqs?
>
> mac80211 does it for some wifi drivers. There used to be IPsec but I
> *think* this moved to the "parallel processing kthread".

I was able to find my way through mac80211 and confirm the use a taslket 
and therefore softirqs. However, I got lost in the ipsec code.

> During my FPU rework on x86 I didn't find anything that does the
> processing in softirq (on my machine) so I hacked something so that I
> could test that I didn't break anythingâ

This is the same on the platform I have been using for testing.

Cheers,

--
Julien Grall