linux-mips
[Top] [All Lists]

Re: [PATCH] MIPS: ASID conflict after CPU hotplug

To: "Kevin D. Kissell" <kevink@paralogos.com>
Subject: Re: [PATCH] MIPS: ASID conflict after CPU hotplug
From: Maksim Rayskiy <maksim.rayskiy@gmail.com>
Date: Mon, 29 Nov 2010 19:21:22 -0800
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZQo9YNrpa7dnmtWWoUZn1I2wnrXUU8xjYyDeHMT1fgU=; b=VKaOmMAR07MnllZI2dT90oajj7oja51Y0tqtoJA5HMn7dbWqKSqQ2RH0bEoBsiQz6c vJNHnmHJnqoxax02x6kYsPgcWm/LIB9a1v16CAqa+qZZIlAFRixJ1RDGZhq04xUvRkmK Zee/Hqaw/rXr/UckhPnTZr/xKqAwlShH2tVxA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Brin27mT2wE/UXO08I+X0igdvXNe4RDKtM4SGo+s8L0HhOujByXCtDvwSTpbkJEvmJ NcMMEbw/ydQDN86CPyilRabYP2z/XHRuAaXiEhbBj76/kMHSbZTbppBoR7htqerwNh7p G7Plj48/3z+6chR2vivhCYSF5Ab5p/AJskKgg=
In-reply-to: <4CF46741.9060902@paralogos.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <AANLkTi=yHm72=sM=QwLpm=aDRnxVf7ZM5=W6eNzgVoTN@mail.gmail.com> <20101122034141.GA13138@linux-mips.org> <4CEAE1EE.9020406@paralogos.com> <AANLkTimuJLxG2KoibRxzcHkX3LoKsTWqJSF_e=ouFi+b@mail.gmail.com> <4CEE877C.7020309@paralogos.com> <AANLkTinUSjvjwHVJoRW-Fr75WDfheq3hSM_hEBMsEUXK@mail.gmail.com> <4CF46741.9060902@paralogos.com>
Sender: linux-mips-bounce@linux-mips.org
On Mon, Nov 29, 2010 at 6:53 PM, Kevin D. Kissell <kevink@paralogos.com> wrote:
> Having done surgery in the past to the ASID management code, this sounds
> like
> a much more rational explanation of the observed problem.  Your proposed mod
> sounds like it might work, but local_flush_tlb_mm() is implemented in terms
> of
> drop_mmu_context(), which only does what you want if the CPU executing the
> code is *not* one of the CPUs participating in the memory map.  Otherwise,
> instead of clearing the ASID in the table, it allocates a new one.  I have a
> concern
> that this may re-randomize things in a way that will solve your problem
> *most*
> of the time, but not always.
>

Actually, if you call this function late enough, specifically when
cpu_online(cpu) is 0, it does exactly what I want from it - that is
clears ASID in the context.
I am calling it from play_dead() which is platform specific, but there
might be a place for it in platform-independent code as well.
Another option would be not to use drop_mmu_context() but rather clear
the context directly, since we know exactly what we want to do at this
point.

> Now that we have a better understanding of the failure, your initial notion
> of *not* restarting the ASID sequence on a hotplug insertion doesn't seem
> as crazy - it's certainly the zen "doing by doing nothing" way to go,
> without
> the iterative overhead of walking the full process table.  But as we
> discussed,
> it has the downside of requiring new state infrastructure for tracking
> hotplugs,
> and we'd want to be sure that it's well behaved in the case where we have a
> post-initial-boot hotplug event that brings a CPU online that has never been
> initialized.  To take that tack, we'd need a per-CPU-slot bit which says "I
> have
> a valid ASID sequence, thank you", which is checked in per_cpu_trap_init()
> (or some other appropriate hook), and the ASID "cache" is initialized only
> if it's needed, which *might* be on a hotplug.

You are talking about adding this bit to cpuinfo_mips, correct?

Maksim.

>
> /K.
>

<Prev in Thread] Current Thread [Next in Thread>