[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy0zq5h7zXcL7KNZuhvVHUZvA__U4ztJvP_WTCN+dub2g@mail.gmail.com>
Date: Wed, 17 Aug 2016 10:32:33 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Denys Vlasenko <dvlasenk@...hat.com>
Cc: Ingo Molnar <mingo@...nel.org>, Andy Lutomirski <luto@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
Alex Deucher <alexander.deucher@....com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Christian König <christian.koenig@....com>,
Vinod Koul <vinod.koul@...el.com>,
Johannes Berg <johannes.berg@...el.com>,
Sara Sharon <sara.sharon@...el.com>,
Adrian Hunter <adrian.hunter@...el.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Petition Intel/AMD to add POPF_IF insn
On Wed, Aug 17, 2016 at 10:20 AM, Denys Vlasenko <dvlasenk@...hat.com> wrote:
> Last year, a proposal was floated to avoid costly POPF.
> In particular, each spin_unlock_irqrestore() does it,
> a rather common operation.
Quiet frankly, it takes so long for hw features that I don't think
it's worth it for something like this.
I'd rather see people play around with just the conditional "sti"
model instead and see how well that works. *Particularly* if we inline
that part of the spin_lock_irqrestore(), the branch prediction logic
may work very well. And even if not, it migth work better than popf.
But somebody would need to run the tests on an actual load
(microbenchmarks wouldn't work, because they wouldn't show the
different branch prediction cases).
power has been using "just do IF in software", which is also an
alternative, but it's much more complicated (you take the interrupt,
notice that the sw disable flag is set, don't actually run the irq but
set a flag and disable irqs for _real_ and return. Then you replay the
irq when enabling the software irq flag again)
Linus
Powered by blists - more mailing lists