From: "Oliver O'Halloran" <oohall@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range()
Date: Tue, 9 Jul 2019 15:29:43 +1000 [thread overview]
Message-ID: <CAOSf1CHYdUXOrxrnEgnF0QXWJ3At=x_70FOhr-9nyuXcgsYk3Q@mail.gmail.com> (raw)
In-Reply-To: <c0461069-8ef8-cb56-6807-71cc79793ac4@linux.ibm.com>
On Tue, Jul 9, 2019 at 12:52 PM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> On 7/9/19 7:50 AM, Oliver O'Halloran wrote:
> > On Tue, Jul 9, 2019 at 12:22 AM Aneesh Kumar K.V
> > <aneesh.kumar@linux.ibm.com> wrote:
> >>
> >> Christophe Leroy <christophe.leroy@c-s.fr> writes:
> >>
> >>> *snip*
> >>> + if (IS_ENABLED(CONFIG_PPC64))
> >>> + isync();
> >>> }
> >>
> >>
> >> Was checking with Michael about why we need that extra isync. Michael
> >> pointed this came via
> >>
> >> https://github.com/mpe/linux-fullhistory/commit/faa5ee3743ff9b6df9f9a03600e34fdae596cfb2#diff-67c7ffa8e420c7d4206cae4a9e888e14
> >>
> >> for 970 which doesn't have coherent icache. So possibly isync there is
> >> to flush the prefetch instructions? But even so we would need an icbi
> >> there before that isync.
> >
> > I don't think it's that, there's some magic in flush_icache_range() to
> > handle dropping prefetched instructions on 970.
> >
> >> So overall wondering why we need that extra barriers there.
> >
> > I think the isync is needed there because the architecture only
> > requires sync to provide ordering. A sync alone doesn't guarantee the
> > dcbfs have actually completed so the isync is necessary to ensure the
> > flushed cache lines are back in memory. That said, as far as I know
> > all the IBM book3s chips from power4 onwards will wait for pending
> > dcbfs when they hit a sync, but that might change in the future.
> >
>
> ISA doesn't list that as the sequence. Only place where isync was
> mentioned was w.r.t icbi where want to discards the prefetch.
doesn't list that as the sequence for what?
> > If it's a problem we could add a cpu-feature section around the isync
> > to no-op it in the common case. However, when I had a look with perf
> > it always showed that the sync was the hotspot so I don't think it'll
> > help much.
> >
>
> What about the preceding barriers (sync; isync;) before dcbf? Why are
> they needed?
Dunno, the sync might just be to ensure ordering between prior stores
and the dcbf.
>
> -aneesh
next prev parent reply other threads:[~2019-07-09 5:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 9:05 [PATCH 1/4] powerpc/64: flush_inval_dcache_range() becomes flush_dcache_range() Christophe Leroy
2019-05-14 9:05 ` [PATCH 2/4] powerpc/32: activate ARCH_HAS_PMEM_API and ARCH_HAS_UACCESS_FLUSHCACHE Christophe Leroy
2019-07-15 6:49 ` Michael Ellerman
2019-07-15 7:02 ` Oliver O'Halloran
2019-07-15 17:03 ` Christophe Leroy
2019-05-14 9:05 ` [PATCH 3/4] powerpc/32: define helpers to get L1 cache sizes Christophe Leroy
2019-07-08 1:19 ` Michael Ellerman
2019-05-14 9:05 ` [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range() Christophe Leroy
2019-07-08 1:19 ` Michael Ellerman
2019-07-08 14:21 ` Aneesh Kumar K.V
2019-07-09 2:20 ` Oliver O'Halloran
2019-07-09 2:51 ` Aneesh Kumar K.V
2019-07-09 5:29 ` Oliver O'Halloran [this message]
2019-07-09 17:04 ` Segher Boessenkool
2019-08-08 6:53 ` powerpc flush_inval_dcache_range() was buggy until v5.3-rc1 (was Re: [PATCH 4/4] powerpc/64: reuse PPC32 static inline flush_dcache_range()) Michael Ellerman
2019-07-08 1:19 ` [PATCH 1/4] powerpc/64: flush_inval_dcache_range() becomes flush_dcache_range() Michael Ellerman
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='CAOSf1CHYdUXOrxrnEgnF0QXWJ3At=x_70FOhr-9nyuXcgsYk3Q@mail.gmail.com' \
--to=oohall@gmail.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).