On 2018-09-19 5:33 PM, Mikulas Patocka wrote:
On Fri, 24 Aug 2018, John David Anglin wrote:
Regarding the TLB code, it turned out we were always setting the page
accessed bit for user pages. So, the code to set it when a user page is
accessed is redundant. We need to lock to update the accessed and dirty
bits atomically. We can keep the current TLB locking code and not set
the page accessed bit in our user page defines. This should improve
swap but the TLB handler is more complex. Another alternative is to
remove the locking and accessed update code from the TLB handler. This
provides the best performance for TLB inserts but swap performance will
be worse since we don't track the accessed bit.
Dave
Perhaps the handler could test the bits without the lock and take the lock
only if they need to be changed. It's hard to say if it would break tlb
flushing code in some subtle way.
Yes, but that would likely require a branch. We have tried to minimize
the use of branches
in the handler.
I favour the update technique used in the patch that I recently posted.
It avoids the slowdown
and the race in setting the accessed and dirty bits. There's still the
occasional memory issue
seen in package builds but I don't think these faults are any more
frequent than on buildds
running with lock.
If we really need a lock, then the routines in pgtable.h that modify the
accessed and dirty bits
likely need locks as well.
BTW. could we use per-mm lock that would be located in the top-level
pagetable? So that the cache line containing the lock would not be moved
between CPUs when multiple processes take tlb faults.
Don't know. The lock address needs to be easily loadable as the number
of shadow registers
is limited.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
