public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Tejun Heo <tj@kernel.org>,
	Christoph Lameter <cl@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	travis@sgi.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	steiner@sgi.com, Hugh Dickins <hugh@veritas.com>
Subject: Re: regarding the x86_64 zero-based percpu patches
Date: Thu, 15 Jan 2009 12:19:02 +1030	[thread overview]
Message-ID: <200901151219.03403.rusty@rustcorp.com.au> (raw)
In-Reply-To: <m1k58zx305.fsf@frodo.ebiederm.org>

On Tuesday 13 January 2009 14:37:38 Eric W. Biederman wrote:
> It isn't incompatible with a per-cpu virtual mapping.  It allows the
> possibility of each cpu reusing the same chunk of virtual address
> space for per cpu memory.

This can be done (IA64 does it today), but it's not generically useful.  You can use it to frob a few simple values, but it means you can't store any pointers, and that just doesn't fly in general kernel code.

> I think it would be nice if the percpu area could grow and would not be
> a fixed size at boot time, I'm not particularly convinced it has to.

I used to be convinced it had to grow, but Christoph showed otherwise.  Nonetheless, it's an annoying restriction which is going to bite us in the ass repeatedly as coders use per_cpu on random sizes.

Rusty.

  parent reply	other threads:[~2009-01-15  3:23 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <49649814.4040005@kernel.org>
     [not found] ` <20090107120225.GA30651@elte.hu>
2009-01-07 12:13   ` regarding the x86_64 zero-based percpu patches Tejun Heo
2009-01-10  6:46     ` Rusty Russell
2009-01-12 17:23       ` Christoph Lameter
2009-01-12 17:44         ` Eric W. Biederman
2009-01-12 19:00           ` Christoph Lameter
2009-01-13  0:33           ` Tejun Heo
2009-01-13  3:01             ` Eric W. Biederman
2009-01-13  3:14               ` Tejun Heo
2009-01-13  4:07                 ` Eric W. Biederman
2009-01-14  3:58                   ` Tejun Heo
2009-01-15  1:47                     ` Rusty Russell
2009-01-15  1:49                   ` Rusty Russell [this message]
2009-01-15 20:26                     ` Christoph Lameter
2009-01-15  1:34           ` Rusty Russell
2009-01-15 13:55             ` Ingo Molnar
2009-01-15 20:27             ` 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=200901151219.03403.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=steiner@sgi.com \
    --cc=tj@kernel.org \
    --cc=travis@sgi.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