mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Christoph Lameter <cl@linux.com>
Cc: akpm@linuxfoundation.org, linux-arch@vger.kernel.org,
	Steven Rostedt <srostedt@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [guv 00/16] [RFC] percpu: Replace __get_cpu_var uses throughout the kernel
Date: Fri, 23 Aug 2013 16:05:14 -0400	[thread overview]
Message-ID: <20130823200514.GA11391@mtj.dyndns.org> (raw)
In-Reply-To: <00000140ac8debd6-6f9e64f9-1107-4336-91ef-77cdf764b96a-000000@email.amazonses.com>

Hello, Christoph.

On Fri, Aug 23, 2013 at 07:01:56PM +0000, Christoph Lameter wrote:
> This patch converts __get_cpu_var into either and explicit address
> calculation using this_cpu_ptr() or into a use of this_cpu
> operations that use the offset. Thereby address calcualtions are
> avoided and less registers are used when code is generated.

Yeah, we should have done this long ago.  Eventually, I think we'd be
better off dropping all _var() accessors.  They were okay when we had
segration between static and dynamic ones but are now just adding to
confusion.

On a cursory scan,

* Each patch probably needs a brief explanation of why this is
  happening, especially if these patches are gonna be routed
  separately.

* It would be a lot easier to route the patches if each had cc's to
  the maintainers of the affected subsystems.

* Dunno what's the convention around conccinelle scripts but do we
  need to keep them around if the accessor being converted gets
  removed at the end of the series?

How do you want to route the patches?  I'm gonna apply the second
patch which updates __verify_pcpu_ptr() to the percpu tree right away
and push it to Linus early during the merge window so that pushing
other patches through different trees from there on isn't too painful.

Thanks.

-- 
tejun

  reply	other threads:[~2013-08-23 20:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-23 19:01 Christoph Lameter
2013-08-23 20:05 ` Tejun Heo [this message]
2013-08-26 15:21   ` Christoph Lameter
2013-08-26 18:18     ` Tejun Heo
2013-08-27  4:57 ` Stephen Rothwell
2013-08-27 15:39   ` Christoph Lameter

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=20130823200514.GA11391@mtj.dyndns.org \
    --to=tj@kernel.org \
    --cc=akpm@linuxfoundation.org \
    --cc=cl@linux.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=srostedt@redhat.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

all inboxes | Powered by JetHome®