On 2022-09-25 1:51 p.m., Helge Deller wrote:
On 9/25/22 16:33, John David Anglin wrote:
I believe this change is wrong and will reduce performance.
Yes, could be. That's why intentionally marked it RFC.
The TLB setup for a TMPALIAS flush is local to any given CPU. So, we
should only need a local TLB purge.
Can those function theoretially be preempted?
If so, could it be scheduled on another CPU where the TMPALIAS isn't flushed?
I think preempt_disable/preempt_enable are used before/after all calls to these routines.
It would be better if these calls were in the flush routines.
A local TLB purge doesn't require locking to serialize PxTLB broadcasts. It is also faster than
a global TLB purges
True.
Indeed, the case that might be wrong is the one that uses pdtlb.
Which do you have in mind here?
The pdtlb instructions in these routines are not serialized. Theoretically, this could result in bus
contention and system malfunction. Maybe only D and R class machines are PA 1.1 and SMP.
It potentially needs serialization
on SMP machines. See comment in pgtable.h.
One goal of that patch was to drop the CONFIG_PA20 ifdef case,
because a 32-bit kernel could be compiled for PA8000 in which case
the "pdtlb,l" will burn the machine.
Don't think so. "pdtlb,l" is available on all PA 2.0 machines. It's not 64-bit specific.
I'll send another patch which takes care of this without changing
the local purges of pdtlb on 64bit CPUs.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
