All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
	Andi Kleen <andi@firstfloor.org>,
	paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	mingo@elte.hu, rjw@sisk.pl, dipankar@in.ibm.com,
	tglx@linuxtronix.de
Subject: Re: [PATCH] rudimentary tracing for Classic RCU
Date: Thu, 9 Oct 2008 10:06:01 +0200	[thread overview]
Message-ID: <20081009080601.GD24560@one.firstfloor.org> (raw)
In-Reply-To: <20081009161232.DEDC.KOSAKI.MOTOHIRO@jp.fujitsu.com>

On Thu, Oct 09, 2008 at 04:14:26PM +0900, KOSAKI Motohiro wrote:
> Hi Lai-san,
> 
> > >> In this case, why not define it as:
> > >> static char buf[20*NR_CPUS + 100];
> > > 
> > > Actually you should near never use NR_CPUS now but always num_possible_cpus()
> > > (or even num_online_cpus()) Using NR_CPUS can lead to extreme waste
> > > of memory on kernels which are compiled for 4096 CPUs for example.
> > > 
> > > And with num_possible_cpus() kmalloc is needed.
> > 
> > I thought the default value of NR_CPUS is 32.
> 
> it's pointless.
> Almost distribution use _very_ large NR_CPUS (likes 4096).

Right now it's more like 8-128, but at least there is some effort
to make a 4096 CPU distribution possible and Mike Travis has been
 tirelessly working on eradicating all the rogue NR_CPUs all over 
the tree.  So it's better to not add more.

> So, We should concern large NR_CPUS.

Agreed.

-Andi

-- 
ak@linux.intel.com

  parent reply	other threads:[~2008-10-09  7:59 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-06 14:12 scheduler hang on cpu re-hotplug with 2.6.27rc8 Andi Kleen
2008-10-06 23:28 ` RCU " Andi Kleen
2008-10-07  3:08   ` Paul E. McKenney
2008-10-07  7:15     ` Andi Kleen
2008-10-07 15:26       ` Paul E. McKenney
2008-10-07 15:49         ` Andi Kleen
2008-10-07 16:34           ` Paul E. McKenney
2008-10-07 21:09             ` Andi Kleen
2008-10-07 21:22               ` Paul E. McKenney
2008-10-09  1:08                 ` [PATCH] rudimentary tracing for Classic RCU Paul E. McKenney
2008-10-09  6:20                   ` Lai Jiangshan
2008-10-09  6:55                     ` Andi Kleen
2008-10-09  7:05                       ` Lai Jiangshan
2008-10-09  7:14                         ` KOSAKI Motohiro
2008-10-09  7:26                           ` Lai Jiangshan
2008-10-09  8:06                           ` Andi Kleen [this message]
2008-10-10 11:48                         ` Paul E. McKenney
2008-10-09 11:50                       ` Paul E. McKenney
2008-10-09 11:50                     ` Paul E. McKenney
2008-10-09 10:23                   ` Frédéric Weisbecker
2008-10-09 10:53                     ` Andi Kleen
2008-10-09 11:44                       ` Frédéric Weisbecker
2008-10-09 11:54                     ` Paul E. McKenney
2008-10-09 13:01                       ` Frédéric Weisbecker
2008-10-10  3:44                   ` [PATCH] v2 " Paul E. McKenney
2008-10-13 23:09                     ` [PATCH] v3 " Paul E. McKenney
2008-10-14  3:53                       ` Lai Jiangshan
2008-10-14 14:35                         ` Paul E. McKenney
2008-10-23 11:12                       ` Lai Jiangshan
2008-10-26 21:59                         ` Paul E. McKenney
2008-10-27 21:50                           ` Paul E. McKenney
2008-10-27 23:57                             ` Paul E. McKenney
2008-10-29  1:16                               ` Paul E. McKenney
2008-10-29  1:31                                 ` Lai Jiangshan
2008-10-30 15:52                                   ` Paul E. McKenney
2008-10-09  1:33                 ` RCU hang on cpu re-hotplug with 2.6.27rc8 Paul E. McKenney
2008-10-09  4:56                   ` Andi Kleen
2008-10-09  7:24                     ` Thomas Gleixner
2008-10-09  8:22                       ` Andi Kleen
2008-10-09 11:44                     ` Paul E. McKenney

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=20081009080601.GD24560@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=dipankar@in.ibm.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rjw@sisk.pl \
    --cc=tglx@linuxtronix.de \
    /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.