All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	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, 09 Feb 2006 13:46:32 +0100	[thread overview]
Message-ID: <43EB39A8.2010202@cosmosbay.com> (raw)
In-Reply-To: <20060209114700.GB20554@osiris.boeblingen.de.ibm.com>

Heiko Carstens a écrit :
>>>>>  > 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...
> 

Then it's OK to clear bits from cpu_possible_map once you have max_cpus value

for (cpu = max_cpus ; cpu < NR_CPUS ; cpu++)
	cpu_clear(cpu, cpu_possible_map);


  reply	other threads:[~2006-02-09 12:46 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-09  8:32 [PATCH] percpu data: only iterate over possible CPUs 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
2006-02-09 12:46               ` Eric Dumazet [this message]
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  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=43EB39A8.2010202@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=76306.1226@compuserve.com \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=dada1@cosmobay.com \
    --cc=heiko.carstens@de.ibm.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 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.