[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwfEzVCdeVdK6hUO4s_yy-wisPmQhtYbNUr4hFuRm8NkQ@mail.gmail.com>
Date: Wed, 17 Aug 2016 12:37:35 -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:32 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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".
That said, the first thing we should test is to just see how the
"let's just optimize this in software" thing works.
Replace the "popf" with "if (val & X86_EFLAGS_IF) local_irq_enable();"
and see how that works out. Play with inlining it or not, and see if
the branch predictor matters.
We may simply not need popf optimizations.
Linus
Powered by blists - more mailing lists