Re: [patch 01/15] mm/memory.c: avoid access flag update TLB flush for retried page fault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 27, 2020 at 10:52 AM Yang Shi <yang.shi@xxxxxxxxxxxxxxxxx> wrote:
>
> It looks normal page is skipped too unless it is a write fault. The
> comment might be a little bit misleading.

No the comment is fine - in that it matches the code.

It's the code _and_ the comment that I find to be garbage.

> Read fault should just change young bit and typically TLB won't get
> flushed if just young bit is changed and TLB flush can be deferred again
> to write fault which may change access permission and/or dirty bit.

This is the part I disagree with.

A read fault could easily cause the exact same issue, exactly because
people do young bits in software too.

It's just harder to trigger, because the young bit is typically set
initially - in ways that the dirty bit easily isn't.

So to get to the "on, young bit wasn't set, the TLB has the 'fault on
access' bit set, *and* we raced on two different CPU's at the same
time" condition is much *much* harder than the write bit is.

But it seems to be no different in theory.

So I think the whole "treat write/dirty specially" thing is complete
garbage. Sure, it speeds things up. But it speeds things up by being
wrong.

                  Linus




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux