This approach certainly makes per_cpu_trap_init() more readable and
maintainable, but it has the downside of creating state and
infrastructure that have footprints elsewhere that add to global cruft
and complexity. Note that your patch, as written, wouldn't solve your
problem, because it doesn't include the code that would actually set and
clear the elements of your cpu_warm_boot[] array. If we do need to pay
attention to warm boot state elsewhere in the kernel (Does any other
architecture? That should be a clue...), then some bits in memory like
that should perhaps be defined (though I'd wonder why it couldn't be a
bit in some existing per-CPU state entity like cpu_data[]). Otherwise,
as I said earlier, the cleanest approach strikes me as one of resetting
the value of EntryHi as well as the ASID cache when the hotplug event
takes place. The cleanest possible outcome would be if one could *move*
the reset initialization of EntryHi from wherever it is now to
per_cpu_trap_init(), so there would be *zero* net additional code, but
it may be (it's Thanksgiving and I'm limited in time and internet
access, so I can't really go look for you) that it's initialized as a
side effect of something that happens repeatedly, such that actually
*moving* it would be dangerous. But if you have the time, try setting
up EntryHi explicitly and unconditionally in per_cpu_trap_init() and see
if it doesn't solve your initial problem.
Happy Holiday to you all,
/K.
On 11/24/10 7:03 PM, Maksim Rayskiy wrote:
I certainly agree that it is a bad idea to look at the current value
of asid_cache when figuring out if it is a warm or cold boot.
I could not tell how the code ended up with this entryHi value after
the hotplug. So, I can only address the simplest portion of issues you
mentioned.
How about we add a variable to tell warm restart from cold and
preserve asid_cache across hotplug event. It is not much of an
improvement over the original code, I must admit.
Signed-off-by: Maksim Rayskiy<maksim.rayskiy@xxxxxxxxx>
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index d83f325..9116adb 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -1489,6 +1489,8 @@ static int __init ulri_disable(char *s)
}
__setup("noulri", ulri_disable);
+static int cpu_warm_boot[NR_CPUS];
+
void __cpuinit per_cpu_trap_init(void)
{
unsigned int cpu = smp_processor_id();
@@ -1577,7 +1579,9 @@ void __cpuinit per_cpu_trap_init(void)
}
#endif /* CONFIG_MIPS_MT_SMTC */
- cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
+ if (!cpu_warm_boot[cpu])
+ cpu_data[cpu].asid_cache = ASID_FIRST_VERSION;
+ cpu_warm_boot[cpu] = 1;
TLBMISS_HANDLER_SETUP();
atomic_inc(&init_mm.mm_count);
On Mon, Nov 22, 2010 at 1:34 PM, Kevin D. Kissell<kevink@xxxxxxxxxxxxx> wrote:
On 11/21/10 19:41, Ralf Baechle wrote:
...
Need to think a little about potencial consequences of your suggested
patch. It seems ok. Kevin, what do you think?
Since you ask, while I would imagine that Maksim's patch works fine for him,
I'm not sure that it's really the right fix. I never did succeed in getting
CPU hotplugging working back in the 2.6.18 days, so I don't know as much
about it as I'd like, but if per_cpu_trap_init() needs to be invoked on a
hot plugin event, and if its behavior needs to be different , I'd really,
really prefer to see that state propagated explicitly, rather than inferring
it from whatever happens to be in cache/memory at cpu_data[cpu].asid_cache.
But beyond that, if the problem arises because setting
cpu_data[cpu].asid_cache to a known initial state on a plugin event can
conflict with the residual content of EntryHi, rather than creating a
special case where we don't initialize the ASID cache, since we seem to be
(re)initializing a lot of other privileged state, why aren't we also setting
a known sane initial EntryHi value? Wouldn't that be a cleaner fix? (And
I don't mean that as a rhetorical question - there may be very good reasons
to let EntryHi values persist across hot unplug/plug events. I just can't
imagine them offhand over coffee.)
/K.
