[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4c31334b-4424-7660-5513-a601bfa763f3@redhat.com>
Date: Wed, 17 Aug 2016 21:35:59 +0200
From: Denys Vlasenko <dvlasenk@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Lutomirski <luto@...capital.net>,
Sara Sharon <sara.sharon@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
Christian König <christian.koenig@....com>,
Vinod Koul <vinod.koul@...el.com>,
Alex Deucher <alexander.deucher@....com>,
Johannes Berg <johannes.berg@...el.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Andy Lutomirski <luto@...nel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Ingo Molnar <mingo@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: RFC: Petition Intel/AMD to add POPF_IF insn
On 08/17/2016 09:32 PM, Linus Torvalds wrote:
> On Wed, Aug 17, 2016 at 12:26 PM, Denys Vlasenko <dvlasenk@...hat.com> wrote:
>>
>> Exactly. And more:
>
> All of which is ENTIRELY IRRELEVANT.
>
> The 2-page pseudo-code is about behavior. It's trivial to
> short-circuit. There are obvious optimizations, which involve just
> making the rare cases go slow and have a trivial "if those bits didn't
> change, don't go through the expense of testing them".
>
> The problem is that IF is almost certainly right now in that rare case
> mask, and so popf is stupidly slow for IF.
I ran the test, see the first email in the thread.
Experimentally, POPF is stupidly slow _always_. 6 cycles
even if none of the "scary" flags are changed.
Either:
* its microcode has no rare case mask
or
* its microcode is so slow that even fast path is slow,
and slow path is worse
Powered by blists - more mailing lists