From: "Kevin D. Kissell" <kevink@paralogos.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Randy MacLeod <rwmacleod@gmail.com>, linux-mips@linux-mips.org
Subject: Re: MIPS: [raw_]smp_processor_id uses current_thread_info
Date: Thu, 24 Sep 2009 11:16:25 -0700 [thread overview]
Message-ID: <4ABBB779.1040201@paralogos.com> (raw)
In-Reply-To: <20090924155129.GA11576@linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 2143 bytes --]
Ralf Baechle wrote:
> On Wed, Sep 23, 2009 at 02:27:26PM -0400, Randy MacLeod wrote:
>
>
>> I'd like advice on changing the implementation of smp_processor_id on
>> Cavium specifically and/or MIPS generally.
>>
>> Currently we have: arch/mips/include/asm/smp.h
>> #define raw_smp_processor_id() (current_thread_info()->cpu)
>>
>> A co-worker has an issue where the current thread pointer is corrupted
>> on a Cavium MIPS system running 2.6.14 (but the same code exists in 2.6.31).
>> During the resulting panic() the kernel calls smp_processor_id()
>> which dereferences the corrupt task pointer again - ouch. I've notice that
>> other arches have raw_smp_processor_id() defined to
>> - a platform specific register read, or
>> - a percpu variable or
>> - have a hard_smp_processor_id() defined
>> This last one is presumably for times when you don't trust the kernel
>> data structures to be
>> sane.
>>
>
> Dereferencing current_thread_info()->cpu is fairly likely to hit in the cache
> so probably a single cycle operation.
Ironically, it's statistically faster than reading a dedicated CP0
register on those cores that have them, even if that were otherwise a
good idea (see below), since access to CP0 registers generally doesn't
pipeline!
> raw_smp_processor_id() is also a
> very common operation so you really don't want to change it to something
> slower except for a debugging kernel.
>
> If you have a good kernel stack pointer you can compute the thread pointer
> from that:
>
> ori $28, sp, _THREAD_MASK
> xori $28, _THREAD_MASK
>
>
>> I can create a patch that calls cvmx_get_core_num(); for cavium.
>> Is there a more generic way to get the cpu number on MIPS?
>>
>
> raw_smp_processor_id() returns the processor ID as counted by Linux. That
> number does not necessarily match the firmware's numbering.
Nor does it necessarily match the MIPS32R2's hardware CPU number in the
EBase register. smp_processor_id() is fundamentally a software concept,
and it's more a lucky coincidence than an ironclad rule when it tracks
hardware/firmware numbering.
Regards,
Kevin K.
[-- Attachment #2: Type: text/html, Size: 2777 bytes --]
prev parent reply other threads:[~2009-09-24 18:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-23 18:27 MIPS: [raw_]smp_processor_id uses current_thread_info Randy MacLeod
2009-09-24 15:51 ` Ralf Baechle
2009-09-24 18:16 ` Kevin D. Kissell [this message]
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=4ABBB779.1040201@paralogos.com \
--to=kevink@paralogos.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=rwmacleod@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).