From: Mike Travis <travis@sgi.com>
To: Rusty Russell <rusty@rustcorp.com.au>
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 07:17:08 -0700 [thread overview]
Message-ID: <48CA79E4.4080101@sgi.com> (raw)
In-Reply-To: <200809121433.23593.rusty@rustcorp.com.au>
Rusty Russell wrote:
> 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.
Yes, the only reason the _nr is there is to be consistent with the
current for_each_cpu_mask{,_nr} functions. What I'd like to do is
convert all calls to use the nr_cpu_ids and if there's some reason
to need to iterate over NR_CPUS range, then you'd use FOR_EACH_CPU_MASK.
And yes, nr_cpu_ids is init'd to NR_CPUS.
Thanks,
Mike
next prev parent reply other threads:[~2008-09-12 14:17 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
2008-09-12 14:17 ` Mike Travis [this message]
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=48CA79E4.4080101@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=jes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=steiner@sgi.com \
--cc=tglx@linutronix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).