[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikocAcVEAHXi3g7z2s+4y3mh5m0bs17iJnUWPhz@mail.gmail.com>
Date: Thu, 6 Jan 2011 10:16:34 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
Cc: linux-kernel@...r.kernel.org,
"Paul E. McKenney" <paulmck@...ibm.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] RCU changes for v2.6.38
On Thu, Jan 6, 2011 at 1:08 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> Please pull the latest core-rcu-for-linus git tree from:
So I pulled, but I'm not convinced about the crazy busy-looping
SRCU_SYNCHRONIZE_DELAY thing.
Why does it do a silly udelay(), instead of just looping over the
srcu_readers_active_idx() for a few times? You're wasting CPU time
anyway, why ask the user how many usecs to waste?
IOW, why isn't that "wait for no active readers" a nice helper
function, and why doesn't it do
for (i = 0; i < CONFIG_SRCU_SYNCHRONIZE_DELAY; i++) {
if (!srcu_readers_active_idx(sp, idx))
return;
udelay(1);
}
while (srcu_readers_active_idx(sp, idx))
schedule_timeout_interruptible(1);
instead? And is it really sane to ask the kernel configurator to come
up with a random value (ie that "CONFIG_SRCU_SYNCHRONIZE_DELAY" is
just stupid and wrong)?
Please fix this. And don't make people answer unanswerable questions.
If YOU and Paul don't know the answer, why the hell do you expect
somebody who does a "make config" to know the answer?
Either pick a number, or pick an algorithm that self-tunes.
Don't use the Kconfig system as a way to tell people that it's their
fault when you made a bad decision. Really.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists