From: "Kevin D. Kissell" <kevink@paralogos.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Maksim Rayskiy <maksim.rayskiy@gmail.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH] MIPS: ASID conflict after CPU hotplug
Date: Mon, 22 Nov 2010 13:34:38 -0800 [thread overview]
Message-ID: <4CEAE1EE.9020406@paralogos.com> (raw)
In-Reply-To: <20101122034141.GA13138@linux-mips.org>
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.
next prev parent reply other threads:[~2010-11-22 21:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-17 18:49 [PATCH] MIPS: ASID conflict after CPU hotplug Maksim Rayskiy
2010-11-22 3:41 ` Ralf Baechle
2010-11-22 18:38 ` Maksim Rayskiy
2010-11-22 21:34 ` Kevin D. Kissell [this message]
[not found] ` <AANLkTimuJLxG2KoibRxzcHkX3LoKsTWqJSF_e=ouFi+b@mail.gmail.com>
2010-11-25 15:57 ` Kevin D. Kissell
[not found] ` <AANLkTinUSjvjwHVJoRW-Fr75WDfheq3hSM_hEBMsEUXK@mail.gmail.com>
2010-11-30 2:53 ` Kevin D. Kissell
2010-11-30 3:21 ` Maksim Rayskiy
2010-11-30 10:05 ` Kevin D. Kissell
2010-11-30 19:49 ` Maksim Rayskiy
2010-12-01 11:51 ` Sergei Shtylyov
2011-11-10 13:09 ` Ralf Baechle
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=4CEAE1EE.9020406@paralogos.com \
--to=kevink@paralogos.com \
--cc=linux-mips@linux-mips.org \
--cc=maksim.rayskiy@gmail.com \
--cc=ralf@linux-mips.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