[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWE3zYN-6h0RkMV9j5kSkSWbJ-nQnjhH=md=ybSR0eZ9Q@mail.gmail.com>
Date: Tue, 25 Jun 2019 13:15:19 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Vincenzo Frascino <vincenzo.frascino@....com>,
linux-arch <linux-arch@...r.kernel.org>,
LAK <linux-arm-kernel@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>, linux-mips@...r.kernel.org,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
Arnd Bergmann <arnd@...db.de>,
Russell King <linux@...linux.org.uk>,
Ralf Baechle <ralf@...ux-mips.org>,
Paul Burton <paul.burton@...s.com>,
Daniel Lezcano <daniel.lezcano@...aro.org>,
Mark Salyzyn <salyzyn@...roid.com>,
Peter Collingbourne <pcc@...gle.com>,
Shuah Khan <shuah@...nel.org>,
Dmitry Safonov <0x7f454c46@...il.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Huw Davies <huw@...eweavers.com>,
Shijith Thotton <sthotton@...vell.com>,
Andre Przywara <andre.przywara@....com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 1/3] lib/vdso: Delay mask application in do_hres()
On Tue, Jun 25, 2019 at 11:27 AM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Tue, 25 Jun 2019, Thomas Gleixner wrote:
>
> > On Tue, 25 Jun 2019, Vincenzo Frascino wrote:
> >
> > CC+ Andy
> >
> > > do_hres() in the vDSO generic library masks the hw counter value
> > > immediately after reading it.
> > >
> > > Postpone the mask application after checking if the syscall fallback is
> > > enabled, in order to be able to detect a possible fallback for the
> > > architectures that have masks smaller than ULLONG_MAX.
> >
> > Right. This only worked on x86 because the mask is there ULLONG_MAX for all
> > VDSO capable clocksources, i.e. that ever worked just by chance.
> >
> > As we talked about that already yesterday, I tested this on a couple of
> > machines and as expected the outcome is uarch dependent. Minimal deviations
> > to both sides and some machines do not show any change at all. I doubt it's
> > possible to come up with a solution which makes all uarchs go faster
> > magically.
> >
> > Though, thinking about it, we could remove the mask operation completely on
> > X86. /me runs tests
>
> Unsurprisingly the results vary. Two uarchs do not care, but they did not
> care about moving the mask either. The other two gain performance and the
> last one falls back to the state before moving the mask. So in general it
> looks like a worthwhile optimization.
>
At one point, I contemplated a different approach: have the "get the
counter" routine return 0 and then do if (unlikely(cycles <= last))
goto fallback. This will remove one branch from the hot path. I got
dubious results when I tried benchmarking it, probably because the
branch in question was always correctly predicted.
Powered by blists - more mailing lists