On Tue, May 16 2023 at 09:45, Russell King wrote:
> On Tue, May 16, 2023 at 04:07:17PM +0800, Baoquan He wrote:
>> It looks like the reason. As Uladzislau pointed out, ARCH-es may
>> have full TLB flush, so won't get trouble from the merged flush
>> in the calculated [min:max] way, e.g arm64 and x86's flush_tlb_kernel_range().
>> However, arm32 seems lacking the ability of full TLB flash. If agreed, I
>> can make a draft patch to do the flush for direct map and VA seperately,
>> see if it works.
>
> The question IMHO is not so much whether there's a full-TLB flush
> available, but whether it is appropriate to use it. If we're only
> wanting to flush a small number of TLB entries but over a sparse
> range (which seems to be Thomas' situation), does it make any sense
> to flush all TLB entries? I don't think it does, but it depends
> how often this occurs. If we're doing it on a regular basis because
> of some workload, then that workload suffers. If it's a rare event
> then maybe that's okay to do.
It does not matter whether it's rare or not.
The scenario which made us look is that CPU0 is housekeeping and CPU1 is
isolated for RT.
Now CPU0 does that flush nonsense and the RT workload on CPU1 suffers
because the compute time is suddenly factor 2-3 larger, IOW, it misses
the deadline. That means a one off event is already a problem.
Thanks,
tglx
