[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0611161515430.2399-100000@iolanthe.rowland.org>
Date: Thu, 16 Nov 2006 15:27:23 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: Thomas Gleixner <tglx@...esys.com>
cc: LKML <linux-kernel@...r.kernel.org>,
Linus Torvalds <torvalds@...l.org>,
john stultz <johnstul@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
David Miller <davem@...emloft.net>,
Arjan van de Ven <arjan@...radead.org>,
Andrew Morton <akpm@...l.org>, Andi Kleen <ak@...e.de>
Subject: Re: BUG: cpufreq notification broken
On Thu, 16 Nov 2006, Thomas Gleixner wrote:
> [PATCH] cpufreq: make the transition_notifier chain use SRCU
> (b4dfdbb3c707474a2254c5b4d7e62be31a4b7da9)
>
> breaks cpu frequency notification users, which register the callback on
> core_init level. Interestingly enough the registration survives the
> uninitialized head, but the registered user is lost by:
>
> static int __init init_cpufreq_transition_notifier_list(void)
> {
> srcu_init_notifier_head(&cpufreq_transition_notifier_list);
> return 0;
> }
> core_initcall(init_cpufreq_transition_notifier_list);
>
> This affects i386, x86_64 and sparc64 AFAICT, which call
> register_notifier early in the arch code.
>
> > The head of the notifier chain needs to be initialized before use;
> > this is done by an __init routine at core_initcall time. If this turns
> > out not to be a good choice, it can easily be changed.
>
> Hmm, there are no static initializers for srcu and the only way to fix
> this up is to move the arch calls to postcore_init.
If you can find a way to invoke init_cpufreq_transition_notifier_list
earlier than core_initcall time, that would be okay. I did it this way
because it was easiest, but earlier should be just as good.
The only requirement is that alloc_percpu() has to be working, so that the
SRCU per-cpu data values can be set up. I don't know how early in the
boot process you can do per-cpu memory allocation.
As an alternative approach, initialization of srcu_notifiers could be
broken up into two pieces, one of which could be done statically. The
part that has to be done dynamically (the SRCU initialization) wouldn't
mess up the notifier chain. Provided the dynamic part is carried out
while the system is still single-threaded, it would be safe.
Alan Stern
-
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