[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyYvu20qHtJ2SuNK3Dd466Hs9m9U3_41E8HtQ6KiRVRKw@mail.gmail.com>
Date: Fri, 26 Oct 2012 11:02:59 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Rik van Riel <riel@...hat.com>
Cc: Michel Lespinasse <walken@...gle.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrea Arcangeli <aarcange@...hat.com>,
Mel Gorman <mgorman@...e.de>,
Johannes Weiner <hannes@...xchg.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH 05/31] x86/mm: Reduce tlb flushes from ptep_set_access_flags()
On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel <riel@...hat.com> wrote:
>
> Would tlb_fix_spurious_fault take care of that on those
> architectures?
.. assuming that they implement it as a real TLB flush, yes.
But maybe the architecture never noticed that it happened to depend on
the fact that we do a cross-CPU invalidate? So a missing
tlb_fix_spurious_fault() implementation could cause a short loop of
repeated page faults, until the IPI happens. And it would be so
incredibly rare that nobody would ever have noticed.
And if that could have happened, then with the cross-cpu invalidate
removed, the "incredibly rare short-lived constant page fault retry"
could turn into "incredibly rare lockup due to infinite page fault
retry due to TLB entry that never turns dirty despite it being marked
dirty by SW in the in-memory page tables".
Very unlikely, I agree. And this is only relevant for the non-x86
case, so changing the x86-specific optimized version is an independent
issue.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists