On 2018-09-21 12:44 PM, Mikulas Patocka wrote:
On Thu, 20 Sep 2018, John David Anglin wrote:
This patch may resolve some races in TLB handling. Hopefully, TLB inserts are
accesses and
protected by spin lock.
If not, we may need to IPI calls and do local purges on PA 2.0.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
- purge_tlb_entries(vma->vm_mm, addr);
set_pte(ptep, pte_mkold(pte));
+ purge_tlb_entries(vma->vm_mm, addr);
I think you don't need to swap set_pte and purge_tlb_entries. This piece
of code can't race with the TLB handlers because they hold the lock. If
you drop the lock from the TLB handlers, it would cause more problems and
it couldn't be saved by swapping set_pte and purge_tlb_entries.
Yes, but it gives me a comfortable feeling that installed TLB entries
are removed after
the new page table entry is installed. Thus, code that tries to access
the page will fault and
install the new PTE value. This assumes PTE inserts are accesses or
they don't get delayed
too much in the handler after the lock is released.
#ifdef CONFIG_SMP
or,COND(=) %r0,\spc,%r0
- sync
- or,COND(=) %r0,\spc,%r0
- stw \spc,0(\tmp)
+ stw,ma \spc,0(\tmp)
Does the standard somewhere say that the "ma" completer works like a
memory barrier? I didn't know about this.
Yes. On PA 2.0, a store with zero offset and the "ma" completer is
supposed to be an
ordered store. This is "o" completer in PA 2.0 mnemonics. According to
page G-2,
all prior accesses are guaranteed to be performed before an ordered
store is performed.
So, it's supposed to be a store with release semantics. On PA 1.X, it
doesn't do anything
special (adds 0 to \tmp register). I used "ma" so code is PA 1.X
compatible. On PA 1.X,
all accesses are supposed to be strongly ordered.
The intent is to ensure the release is done after all the "accesses"
inside the lock region.
The ldcw is the barrier at the start.
The "sync" barrier degraded performance noticeably.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
