Linux MIPS Architecture development
 help / color / mirror / Atom feed
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.

  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