From: David Howells <dhowells@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "David S. Miller" <davem@davemloft.net>,
olof@lixom.net, linux-arch@vger.kernel.org, paulus@samba.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
Date: Wed, 10 May 2006 11:14:53 +0100 [thread overview]
Message-ID: <14201.1147256093@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <1147245709.32448.74.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > That first cache line of current_thread_info() should be so hot that
> > it's probably just fine to use current_thread_info()->task since
> > you're just doing a mask on a fixed register (r1) to implement that.
>
> Iirc, he tried that, though it did bloat the kernel size a bit due the
> the amount of occurences of current-> in there. We are now thinking
> about either dedicating a register to current (that would avoid the
> problem of printk() using it in start_kernel before we get the per-cpu
> areas setup) in addition to __thread (heh, we have lots of registers on
> ppc :) or maybe putting current back in the paca...
I dedicated registers to current and current threadinfo in the FRV arch. As I
recall doing that improved both performance and code size quite a bit. It also
means that I get sensible bug panic reports when the stack pointer overruns the
stack space.
David
WARNING: multiple messages have this Message-ID (diff)
From: David Howells <dhowells@redhat.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, paulus@samba.org, olof@lixom.net,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables
Date: Wed, 10 May 2006 11:14:53 +0100 [thread overview]
Message-ID: <14201.1147256093@warthog.cambridge.redhat.com> (raw)
In-Reply-To: <1147245709.32448.74.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > That first cache line of current_thread_info() should be so hot that
> > it's probably just fine to use current_thread_info()->task since
> > you're just doing a mask on a fixed register (r1) to implement that.
>
> Iirc, he tried that, though it did bloat the kernel size a bit due the
> the amount of occurences of current-> in there. We are now thinking
> about either dedicating a register to current (that would avoid the
> problem of printk() using it in start_kernel before we get the per-cpu
> areas setup) in addition to __thread (heh, we have lots of registers on
> ppc :) or maybe putting current back in the paca...
I dedicated registers to current and current threadinfo in the FRV arch. As I
recall doing that improved both performance and code size quite a bit. It also
means that I get sensible bug panic reports when the stack pointer overruns the
stack space.
David
next prev parent reply other threads:[~2006-05-10 10:16 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 4:03 [RFC/PATCH] Make powerpc64 use __thread for per-cpu variables Paul Mackerras
2006-05-10 5:16 ` Olof Johansson
2006-05-10 5:16 ` Olof Johansson
2006-05-10 5:35 ` Alan Modra
2006-05-10 5:35 ` Alan Modra
2006-05-10 6:22 ` David S. Miller
2006-05-10 6:22 ` David S. Miller
2006-05-10 6:29 ` Paul Mackerras
2006-05-10 6:29 ` Paul Mackerras
2006-05-10 6:39 ` David S. Miller
2006-05-10 6:39 ` David S. Miller
2006-05-10 7:21 ` Benjamin Herrenschmidt
2006-05-10 7:21 ` Benjamin Herrenschmidt
2006-05-10 10:14 ` David Howells [this message]
2006-05-10 10:14 ` David Howells
2006-05-10 7:41 ` Paul Mackerras
2006-05-10 7:41 ` Paul Mackerras
2006-05-10 15:47 ` Richard Henderson
2006-05-10 15:47 ` Richard Henderson
2006-05-10 15:47 ` Richard Henderson
2006-05-10 18:04 ` Steven Rostedt
2006-05-10 18:04 ` Steven Rostedt
2006-05-10 19:40 ` David S. Miller
2006-05-10 19:40 ` David S. Miller
2006-05-10 21:05 ` Paul Mackerras
2006-05-10 21:05 ` Paul Mackerras
2006-05-10 22:25 ` David S. Miller
2006-05-10 22:25 ` David S. Miller
2006-05-10 23:17 ` Segher Boessenkool
2006-05-10 23:17 ` Segher Boessenkool
2006-05-11 0:22 ` Richard Henderson
2006-05-11 0:22 ` Richard Henderson
2006-05-11 23:41 ` Segher Boessenkool
2006-05-11 23:41 ` Segher Boessenkool
2006-05-11 1:04 ` Alan Modra
2006-05-11 1:04 ` Alan Modra
2006-05-11 1:21 ` Paul Mackerras
2006-05-11 1:21 ` Paul Mackerras
2006-05-11 2:01 ` Alan Modra
2006-05-11 2:01 ` Alan Modra
2006-05-11 23:42 ` Segher Boessenkool
2006-05-11 23:42 ` Segher Boessenkool
2006-05-10 23:05 ` Paul Mackerras
2006-05-10 23:05 ` Paul Mackerras
2006-05-10 23:44 ` Paul Mackerras
2006-05-11 0:11 ` David S. Miller
2006-05-11 0:11 ` David S. Miller
2006-05-18 23:50 ` Paul Mackerras
2006-05-18 23:50 ` Paul Mackerras
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=14201.1147256093@warthog.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=olof@lixom.net \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.