From: Rusty Russell <rusty@rustcorp.com.au>
To: Mike Travis <travis@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>, Jack Steiner <steiner@sgi.com>,
Jes Sorensen <jes@sgi.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] cpumask: add for_each_online_cpu_mask_nr function
Date: Fri, 12 Sep 2008 14:33:22 +1000 [thread overview]
Message-ID: <200809121433.23593.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20080909155013.735125000@polaris-admin.engr.sgi.com>
On Wednesday 10 September 2008 01:50:14 Mike Travis wrote:
> * Add for_each_online_cpu_mask_nr() function to eliminate need for
> a common use of a temporary cpumask_t variable. When the following
> procedure is being used:
>
> funcproto(cpumask_t *mask, ...)
> {
> cpumask_t temp;
>
> cpus_and(temp, *mask, cpu_online_map);
> for_each_cpu_mask_nr(cpu, temp)
> ...
>
> If then becomes:
>
> funcproto(cpumask_t *mask, ...)
> {
> for_each_online_cpu_mask_nr(cpu, *mask)
> ...
>
> * Note the generic __next_cpu_and (and __next_cpu_and_nr) functions
> allowing AND'ing with any cpumask_t variable, not just the
> cpu_online_map.
Good idea! But I really dislike the _nr versions (too many names!). Do we
really need them, since by definition cpus after nr_cpu_ids are never
online...
(And we should initialize nr_cpu_ids to NR_CPUS so even early boot works, if
we don't already...).
Cheers,
Rusty.
next prev parent reply other threads:[~2008-09-12 4:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 15:50 [PATCH 0/3] x86: remove extraneous stack cpumask variables Mike Travis
2008-09-09 15:50 ` [PATCH 1/3] cpumask: add for_each_online_cpu_mask_nr function Mike Travis
2008-09-12 4:33 ` Rusty Russell [this message]
2008-09-12 14:17 ` Mike Travis
2008-09-09 15:50 ` [PATCH 2/3] x86: modify send_IPI_mask interface to accept cpumask_t pointers Mike Travis
2008-09-09 15:50 ` [PATCH 3/3] sched: Optimize cpumask temp stack usage in kernel/sched.c Mike Travis
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=200809121433.23593.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.de \
--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