From: Mike Travis <travis@sgi.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
davej@codemonkey.org.uk, David Miller <davem@davemloft.net>,
Eric Dumazet <dada1@cosmosbay.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Jack Steiner <steiner@sgi.com>,
Jeremy Fitzhardinge <jeremy@goop.org>, Jes Sorensen <jes@sgi.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org,
Christoph Lameter <cl@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [RFC] CPUMASK: proposal for replacing cpumask_t
Date: Thu, 11 Sep 2008 08:04:58 -0700 [thread overview]
Message-ID: <48C9339A.4030309@sgi.com> (raw)
In-Reply-To: <1221123630.4415.1136.camel@twins.programming.kicks-ass.net>
Peter Zijlstra wrote:
...
>> So in function prototypes:
>>
>> cpumask_t function(const cpumask_t *A,
>> cpumask_t *B,
>> cpumask_t cpumask_C)
>>
>> becomes:
>>
>> cpumask_val function(cpumask_t A,
>> cpumask_var B,
>> cpumask_t cpumask_C)
>
> I guess we have to stick the const into the typedef otherwise we get a
> const pointer instead of a const array member, right?
>
> In which case I much prefer the following names:
>
> cpumask_data_t - value
>
> const_cpumask_t - pointer to constant value
> cpumask_t - pointer to value
There were some comments previously such that we should "imply" that the
incoming cpumask_t args are const, so the compiler would flag those
who arbitrarily modify it.
>
...
>> alloc_cpumask(&mask);
>
> Don't you have to deal with allocation errors?
In a perfect world, no... ;-)
...
>> static inline void alloc_cpumask(cpumask_t *m)
>> {
>> cpumask_t d = kmalloc(BYTES_PER_CPUMASK, GFP_KERNEL);
>> if (no_cpumask(&d))
>> BUG();
>
> yuckery yuck yuck!
>
>> *m = d;
>> }
>>
>> static inline void alloc_cpumask_nopanic(cpumask_t *m)
>> {
>> cpumask_t d = kmalloc(BYTES_PER_CPUMASK, GFP_KERNEL);
>>
>> *m = d;
>> }
>
> gah - at the very least you got the naming wrong, methinks the one
> panic-ing should have panic in its name - if you really want to persist
> with that variant.
Yeah, I rather rushed through the allocation part (yuck indeed ;-).
There are some other alternatives:
- reserve one or more of these in the task struct
- reserve one or more in a per-cpu area
- setup some kind of allocation pool similar to alloc_bootmem
- ???
Thanks,
Mike
next prev parent reply other threads:[~2008-09-11 15:05 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-06 23:50 [RFC 00/13] smp: reduce stack requirements for genapic send_IPI_mask functions Mike Travis
2008-09-06 23:50 ` [RFC 01/13] smp: modify send_IPI_mask interface to accept cpumask_t pointers Mike Travis
2008-09-06 23:50 ` [RFC 02/13] cpumask: add for_each_online_cpu_mask_nr function Mike Travis
2008-09-06 23:50 ` [RFC 03/13] xen: use new " Mike Travis
2008-09-06 23:50 ` [RFC 04/13] cpumask: add cpumask_ptr operations Mike Travis
2008-09-06 23:50 ` [RFC 05/13] cpumask: add get_cpumask_var debug operations Mike Travis
2008-09-06 23:50 ` [RFC 06/13] genapic: use get_cpumask_var operations for allbutself cpumask_ts Mike Travis
2008-09-06 23:50 ` [RFC 07/13] sched: Reduce stack size requirements in kernel/sched.c Mike Travis
2008-09-07 10:24 ` Peter Zijlstra
2008-09-07 11:00 ` Andrew Morton
2008-09-07 13:05 ` Peter Zijlstra
2008-09-08 14:56 ` Mike Travis
2008-09-07 20:28 ` Peter Zijlstra
2008-09-08 14:54 ` Mike Travis
2008-09-08 15:05 ` Peter Zijlstra
2008-09-08 18:38 ` Ingo Molnar
2008-09-10 22:47 ` [RFC] CPUMASK: proposal for replacing cpumask_t Mike Travis
2008-09-10 22:53 ` Andi Kleen
2008-09-10 23:33 ` Mike Travis
2008-09-11 5:21 ` Andi Kleen
2008-09-11 9:00 ` Peter Zijlstra
2008-09-11 15:04 ` Mike Travis [this message]
2008-09-12 4:55 ` Rusty Russell
2008-09-12 14:28 ` Mike Travis
2008-09-12 22:02 ` Rusty Russell
2008-09-12 22:50 ` Mike Travis
2008-09-12 22:58 ` H. Peter Anvin
2008-09-06 23:50 ` [RFC 08/13] cpufreq: Reduce stack size requirements in acpi-cpufreq.c Mike Travis
2008-09-06 23:50 ` [RFC 09/13] genapic: reduce stack pressuge in io_apic.c step 1 temp cpumask_ts Mike Travis
2008-09-08 11:01 ` Andi Kleen
2008-09-08 16:03 ` Mike Travis
2008-09-06 23:50 ` [RFC 10/13] genapic: reduce stack pressuge in io_apic.c step 2 internal abi Mike Travis
2008-09-06 23:50 ` [RFC 11/13] genapic: reduce stack pressuge in io_apic.c step 3 target_cpus Mike Travis
2008-09-07 7:55 ` Bert Wesarg
2008-09-07 9:13 ` Ingo Molnar
2008-09-08 15:01 ` Mike Travis
2008-09-08 15:29 ` Mike Travis
2008-09-06 23:50 ` [RFC 12/13] genapic: reduce stack pressuge in io_apic.c step 4 vector allocation Mike Travis
2008-09-06 23:50 ` [RFC 13/13] genapic: reduce stack pressuge in io_apic.c step 5 cpu_mask_to_apicid Mike Travis
2008-09-07 7:36 ` [RFC 00/13] smp: reduce stack requirements for genapic send_IPI_mask functions Ingo Molnar
2008-09-08 15:17 ` 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=48C9339A.4030309@sgi.com \
--to=travis@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=dada1@cosmosbay.com \
--cc=davej@codemonkey.org.uk \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=jes@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--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).