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 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.