[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyrwdH1ege_rcHp9JDAcwGoqDcCrYHGTBU2HFjXgSJN5w@mail.gmail.com>
Date: Wed, 17 Aug 2016 12:32:03 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Denys Vlasenko <dvlasenk@...hat.com>
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 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.
That in no way means that it *has* to be slow for IF, and more
importantly, the other flags don't even come into play. Forget about
them.
Linus
Powered by blists - more mailing lists