From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <andi@firstfloor.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
Jack Steiner <steiner@sgi.com>, Jan Beulich <JBeulich@novell.com>,
Borislav Petkov <bp@amd64.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Nick Piggin <npiggin@kernel.dk>,
"x86@kernel.org" <x86@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@redhat.com>,
tee@sgi.com, Nikanth Karthikesan <knikanth@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible
Date: Fri, 25 Mar 2011 10:22:27 +0100 [thread overview]
Message-ID: <20110325092227.GA13640@elte.hu> (raw)
In-Reply-To: <20110324235654.GM21838@one.firstfloor.org>
* Andi Kleen <andi@firstfloor.org> wrote:
> > never EVER seen any good explanation of why that particular sh*t
> > argument would b true. It seems to be purely about politics, where
> > some idiotic vendor (namely HP) has convinced Intel that they really
> > need it. To the point where some engineers seem to have bought into
> > the whole thing and actually believe that fairy tale ("firmware can do
> > better" - hah! They must be feeding people some bad drugs at the
> > cafeteria)
>
> For the record I don't think it's a good idea for the BIOS to do
> this (and I'm not aware of any engineer who does),
There's really just two sane options:
- complain about the BIOS corrupting CPU state and refusing to use the PMU
- complain about the BIOS corrupting CPU state and using the PMU against the BIOS
We went for the first one but i'll be more than glad to implement Linus's much
more aggressive second option.
Btw., for the record, the thing you have been advocating in the past was a
third option: for the kernel to step aside quietly and to let the BIOS corrupt
a counter or two. You even sent us some sort of BIOS specification about how to
implement that. That's pretty much the worst solution imaginable.
Thanks,
Ingo
next prev parent reply other threads:[~2011-03-25 9:23 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-24 4:56 [PATCH RFC] x86: avoid atomic operation in test_and_set_bit_lock if possible Nikanth Karthikesan
2011-03-24 8:52 ` Jan Beulich
2011-03-24 8:56 ` Ingo Molnar
2011-03-24 14:52 ` Borislav Petkov
2011-03-24 16:48 ` Jan Beulich
2011-03-24 17:19 ` Ingo Molnar
2011-03-25 10:06 ` Jan Beulich
2011-03-25 11:10 ` Ingo Molnar
2011-03-25 12:04 ` Nikanth Karthikesan
2011-03-25 13:12 ` Jack Steiner
2011-03-25 16:29 ` Linus Torvalds
2011-03-25 16:47 ` Jan Beulich
2011-03-25 16:49 ` Jack Steiner
2011-03-24 17:30 ` Jack Steiner
2011-03-24 20:00 ` Ingo Molnar
2011-03-24 20:40 ` Andi Kleen
2011-03-24 20:50 ` Ingo Molnar
2011-03-24 21:37 ` Andi Kleen
2011-03-24 20:48 ` Eric Dumazet
2011-03-24 20:54 ` Ingo Molnar
2011-03-24 21:02 ` Eric Dumazet
2011-03-24 21:42 ` Andi Kleen
2011-03-24 23:26 ` Linus Torvalds
2011-03-24 23:56 ` Andi Kleen
2011-03-25 5:47 ` Eric Dumazet
2011-03-25 9:32 ` Ingo Molnar
2011-03-25 9:44 ` Eric Dumazet
2011-03-25 9:59 ` Ingo Molnar
2011-03-25 10:50 ` Borislav Petkov
2011-03-25 11:10 ` Peter Zijlstra
2011-03-25 11:11 ` Ingo Molnar
2011-03-25 16:16 ` Robert Richter
2011-03-25 17:22 ` Andi Kleen
2011-03-25 19:26 ` Ingo Molnar
2011-03-25 9:38 ` Eric Dumazet
2011-03-25 20:29 ` Peter Zijlstra
2011-03-26 8:15 ` Eric Dumazet
2011-03-26 9:44 ` Peter Zijlstra
2011-03-26 9:57 ` Ingo Molnar
2011-03-25 9:22 ` Ingo Molnar [this message]
2011-03-25 10:21 ` Peter Zijlstra
2011-03-25 16:08 ` Robert Richter
2011-03-25 19:31 ` Ingo Molnar
2011-03-25 17:15 ` Andi Kleen
2011-03-25 19:21 ` Ingo Molnar
2011-03-25 9:35 ` Ingo Molnar
2011-03-24 17:01 ` Linus Torvalds
2011-03-24 17:13 ` Jack Steiner
2011-03-24 18:38 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110325092227.GA13640@elte.hu \
--to=mingo@elte.hu \
--cc=JBeulich@novell.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=bp@amd64.org \
--cc=eric.dumazet@gmail.com \
--cc=hpa@zytor.com \
--cc=knikanth@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=npiggin@kernel.dk \
--cc=steiner@sgi.com \
--cc=tee@sgi.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox