All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Yanmin Zhang <yanmin_zhang@linux.intel.com>
Cc: ShuoX Liu <shuox.liu@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: percpu: Add PCPU_FC_FIXED to pcpu_fc for setting fixed pcpu_atom_size.
Date: Fri, 27 Apr 2012 09:34:30 -0700	[thread overview]
Message-ID: <20120427163430.GQ27486@google.com> (raw)
In-Reply-To: <1335488964.14538.159.camel@ymzhang.sh.intel.com>

Hello,

On Fri, Apr 27, 2012 at 09:09:24AM +0800, Yanmin Zhang wrote:
> > > We can't fix FC_PAGE power regression. If we do so, we need contact many
> > > hardware architects. Current kernel supports FC_PAGE and PMD_SIZE, why
> > > not to allow admin to choose other values?
> > 
> > If this is something which is met in the field commonly, we need to
> > fix the default behavior rather than introducing some arcane boot
> > param.
>
> We just add a new value input method instead of introducing new parameter.

Ummm... I don't know what you meant by the above sentence but adding a
new magic kernel param whether it's part of an existing one or not, is
not a good solution.  They're difficult to discover and not many
actually understand what they do.  If you *have* to add some, then you
better make it clear where it's being applied for what.  ie. in this
case, add something like x86_percpu_embed_unit_size.

> >   IIRC, the reasons PMD_SIZE is used for atom_size are so that
> > percpu areas are aligned to PSE mapping, maybe later we can make use
> > of PSE mapping in vmalloc area too, and it didn't seem to hurt
> > anything.
>
> Well, vmalloc area might use different prot to map physical pages.
> So sharing one PMD huge page by many vmalloc areas might be not good.

Percpu allocator uses the whole vmalloc chunk, so there's no prot
problem.  They're all percpu memory.

Thanks.

-- 
tejun

      parent reply	other threads:[~2012-04-27 16:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-25  8:49 [PATCH] mm: percpu: Add PCPU_FC_FIXED to pcpu_fc for setting fixed pcpu_atom_size ShuoX Liu
2012-04-25 22:24 ` Tejun Heo
2012-04-26  2:01   ` Yanmin Zhang
2012-04-26 22:49     ` Tejun Heo
2012-04-27  1:09       ` Yanmin Zhang
2012-04-27  8:56         ` Yanmin Zhang
2012-04-27 16:53           ` [PATCH] percpu, x86: don't use PMD_SIZE as embedded atom_size on 32bit Tejun Heo
2012-04-27 17:17             ` H. Peter Anvin
2012-04-27 17:27               ` Tejun Heo
2012-04-27 17:21             ` Christoph Lameter
2012-04-27 17:27               ` Tejun Heo
2012-04-27 17:39             ` [PATCH v2] " Tejun Heo
2012-04-27 17:51               ` H. Peter Anvin
2012-04-27 17:53                 ` Tejun Heo
2012-04-28  2:18             ` [PATCH] " ShuoX Liu
2012-04-27 16:34         ` Tejun Heo [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=20120427163430.GQ27486@google.com \
    --to=tj@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shuox.liu@intel.com \
    --cc=yanmin_zhang@linux.intel.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 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.