From: Ley Foon Tan <ley.foon.tan@intel.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
nios2-dev@lists.rocketboards.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH 01/11] nios2: update_mmu_cache clear the old entry from the TLB
Date: Mon, 01 Oct 2018 23:24:23 +0800 [thread overview]
Message-ID: <1538407463.3190.1.camel@intel.com> (raw)
In-Reply-To: <20180929113712.6dcfeeb3@roar.ozlabs.ibm.com>
On Sat, 2018-09-29 at 11:37 +1000, Nicholas Piggin wrote:
> Hi,
>
> Did you get a chance to look at these?
>
> This first patch 1/11 solves the lockup problem that Guenter reported
> with my changes to core mm code. So I plan to resubmit my patches
> to Andrew's -mm tree with this patch to avoid nios2 breakage.
>
> Thanks,
> Nick
Do you have git repo that contains these patches? If not, can you send
them as attachment to my email?
Regards
Ley Foon
>
> On Mon, 24 Sep 2018 01:08:20 +1000
> Nicholas Piggin <npiggin@gmail.com> wrote:
>
> >
> > Fault paths like do_read_fault will install a Linux pte with the
> > young
> > bit clear. The CPU will fault again because the TLB has not been
> > updated, this time a valid pte exists so handle_pte_fault will just
> > set the young bit with ptep_set_access_flags, which flushes the
> > TLB.
> >
> > The TLB is flushed so the next attempt will go to the fast TLB
> > handler
> > which loads the TLB with the new Linux pte. The access then
> > proceeds.
> >
> > This design is fragile to depend on the young bit being clear after
> > the initial Linux fault. A proposed core mm change to immediately
> > set
> > the young bit upon such a fault, results in ptep_set_access_flags
> > not
> > flushing the TLB because it finds no change to the pte. The
> > spurious
> > fault fix path only flushes the TLB if the access was a store. If
> > it
> > was a load, then this results in an infinite loop of page faults.
> >
> > This change adds a TLB flush in update_mmu_cache, which removes
> > that
> > TLB entry upon the first fault. This will cause the fast TLB
> > handler
> > to load the new pte and avoid the Linux page fault entirely.
> >
> > Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> > ---
> > arch/nios2/mm/cacheflush.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/nios2/mm/cacheflush.c
> > b/arch/nios2/mm/cacheflush.c
> > index 506f6e1c86d5..d58e7e80dc0d 100644
> > --- a/arch/nios2/mm/cacheflush.c
> > +++ b/arch/nios2/mm/cacheflush.c
> > @@ -204,6 +204,8 @@ void update_mmu_cache(struct vm_area_struct
> > *vma,
> > struct page *page;
> > struct address_space *mapping;
> >
> > + flush_tlb_page(vma, address);
> > +
> > if (!pfn_valid(pfn))
> > return;
> >
next prev parent reply other threads:[~2018-10-01 7:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180923150830.6096-1-npiggin@gmail.com>
[not found] ` <20180923150830.6096-2-npiggin@gmail.com>
2018-09-29 1:37 ` [RFC PATCH 01/11] nios2: update_mmu_cache clear the old entry from the TLB Nicholas Piggin
2018-10-01 15:24 ` Ley Foon Tan [this message]
2018-10-02 0:06 ` Nicholas Piggin
2018-10-03 3:52 ` Nicholas Piggin
2018-10-05 1:52 ` Ley Foon Tan
2018-10-08 7:16 ` Nicholas Piggin
2018-10-08 17:02 ` Ley Foon Tan
2018-10-08 9:21 ` Nicholas Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1538407463.3190.1.camel@intel.com \
--to=ley.foon.tan@intel.com \
--cc=linux-mm@kvack.org \
--cc=linux@roeck-us.net \
--cc=nios2-dev@lists.rocketboards.org \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.