mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: 76306.1226@compuserve.com, pj@sgi.com, wli@holomorphy.com,
	ak@muc.de, mingo@elte.hu, torvalds@osdl.org,
	linux-kernel@vger.kernel.org, riel@redhat.com,
	dada1@cosmobay.com
Subject: Re: [PATCH] percpu data: only iterate over possible CPUs
Date: Thu, 9 Feb 2006 12:47:00 +0100	[thread overview]
Message-ID: <20060209114700.GB20554@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <20060209023106.10c53c0b.akpm@osdl.org>

> > > >  > Actually, x86 appears to be the only arch which suffers this braindamage. 
> > > >  > The rest use CPU_MASK_NONE (or just forget to initialise it and hope that
> > > >  > CPU_MASK_NONE equals all-zeroes).
> > > > 
> > > >  s390 will join, as soon as the cpu_possible_map fix is merged...
> > > 
> > > What cpu_possible_map fix?
> > 
> > This one:
> > 
> > http://lkml.org/lkml/2006/2/8/162
> > 
> 
> Oh, OK.  Ow, I don't think you want to do that.  It means that all those
> for_each_cpu() loops will now be iterating over all NR_CPUS cpus, whether
> or not they're even possible.

That's ok. We're mainly running under z/VM where you can attach new virtual
cpus on the fly to the virtual machine (up to 64 cpus).
The only difference to before is that it was possible to limit the waste of
resources by passing a number with 'maxcpus'. This value was used to generate
the cpu_possible_map.
But since the map needs to be ready when we return from setup_arch, we don't
have access to max_cpus, unless we parse commandline on our own...

Heiko

  reply	other threads:[~2006-02-09 11:47 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-09  8:32 Chuck Ebbert
2006-02-09  8:55 ` Paul Jackson
2006-02-09  9:06 ` Andrew Morton
2006-02-09  9:11   ` Andrew Morton
2006-02-09 10:08     ` Heiko Carstens
2006-02-09 10:13       ` Andrew Morton
2006-02-09 10:23         ` Heiko Carstens
2006-02-09 10:31           ` Andrew Morton
2006-02-09 11:47             ` Heiko Carstens [this message]
2006-02-09 12:46               ` Eric Dumazet
2006-02-09 13:12                 ` Heiko Carstens
2006-02-09 13:55                   ` Eric Dumazet
     [not found] <200602051959.k15JxoHK001630@hera.kernel.org>
2006-02-07 15:15 ` Heiko Carstens
2006-02-07 15:31   ` Jens Axboe
2006-02-07 16:25   ` Eric Dumazet
2006-02-07 16:42     ` Linus Torvalds
2006-02-07 17:34       ` Andrew Morton
2006-02-07 17:48         ` Linus Torvalds
2006-02-07 18:30           ` Dipankar Sarma
2006-02-07 18:43             ` Linus Torvalds
2006-02-07 18:53               ` Dipankar Sarma
2006-02-07 19:11                 ` Linus Torvalds
2006-02-08  4:40                   ` Heiko Carstens
2006-02-08  8:55                   ` Ivan Kokshaysky
2006-02-08 22:31 ` Rik van Riel
2006-02-09  1:20   ` Rik van Riel
2006-02-09  3:05   ` Andrew Morton
2006-02-09  3:08     ` Andrew Morton
2006-02-09  4:36       ` Eric Dumazet
2006-02-09  4:45         ` Andrew Morton
2006-02-09  4:56           ` Paul Jackson
2006-02-09 16:08           ` Nathan Lynch
2006-02-09 16:13             ` Heiko Carstens
2006-02-09 16:38               ` Rik van Riel
2006-02-09 16:59               ` Nathan Lynch
2006-02-09 17:37               ` Andi Kleen
2006-02-10 10:05                 ` Heiko Carstens
2006-02-10 10:13                   ` Andi Kleen
2006-02-11 14:49                     ` Heiko Carstens
2006-02-11 18:04                       ` Andi Kleen
2006-02-09 17:03             ` Ashok Raj
2006-02-09 17:23               ` Nathan Lynch
2006-02-09 18:04               ` Andrew Morton
2006-02-09 18:52                 ` Ashok Raj
2006-02-09 20:37                   ` Andrew Morton
2006-02-09 21:03                     ` Ashok Raj
2006-02-10 10:02                 ` Andi Kleen
2006-02-10 10:42                   ` Andrew Morton
2006-02-10 11:09                     ` Eric Dumazet
2006-02-10 11:23                       ` Andrew Morton
2006-02-10 11:26                         ` Andrew Morton
2006-02-10 14:13                         ` Eric Dumazet
2006-02-11  0:10                           ` Nathan Lynch
2006-02-11  0:25                             ` Andrew Morton
2006-02-10 12:10                     ` Andi Kleen
2006-02-10 19:08                       ` Andrew Morton
2006-02-09  4:39   ` Eric Dumazet
2006-02-09  4:46     ` Nick Piggin

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=20060209114700.GB20554@osiris.boeblingen.de.ibm.com \
    --to=heiko.carstens@de.ibm.com \
    --cc=76306.1226@compuserve.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=dada1@cosmobay.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pj@sgi.com \
    --cc=riel@redhat.com \
    --cc=torvalds@osdl.org \
    --cc=wli@holomorphy.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®