On 2018-09-20 11:15 AM, Mikulas Patocka wrote:
On Thu, 20 Sep 2018, John David Anglin wrote:
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.
If the branch jumps mostly one way, the predictor should learn about it.
Are there some hardware restrictions on the functionality of the branch
predictor from fault handlers?
As far a I know, the branch predictor has not been enabled. So, we have
static branch prediction
as described in the arch. Generally, it is possible to choose a branch
that will be correctly predicted.
Dave
--
John David Anglin dave.anglin@xxxxxxxx
