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? Mikulas
