From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Christoph Lameter <cl@linux.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Tejun Heo <tj@kernel.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: [cpuops cmpxchg double V2 1/4] Generic support for this_cpu_cmpxchg_double
Date: Fri, 21 Jan 2011 13:10:51 -0500 [thread overview]
Message-ID: <20110121181051.GC12150@Krystal> (raw)
In-Reply-To: <alpine.DEB.2.00.1101211146320.15692@router.home>
* Christoph Lameter (cl@linux.com) wrote:
> On Fri, 21 Jan 2011, Mathieu Desnoyers wrote:
>
> > > this_cpu_cmpxchg_double(percpu_dd, oldword1, oldword2, newword1, newword2)
> > >
> > > with the problem of type checking
> >
> > What is the problem with type checking here ?
>
> You need to know the fields in the struct to do the type checking with
> each of the other parameters.
Isn't that a bit much to try to match the type of each oldword/newword
parameter to the structure fields ? Having separated word 1-2 parameter is just
an artefact caused by the inability of some gcc to deal with int128; were we to
use int128, we would have none of this type-checking whatsoever.
We could simply check that the first parameter alignment is >= 2 * sizeof(long)
and that its size == 2 * sizeof(long), so that the layout in memory fits the
cmpxchg_double requirements. This should work both for structure and array
parameters.
Now if the user needs to map "oldword1, oldword2" to the actual percpu_dd
fields, we could ensure that the order of these two parameters actually match
the structure field or array index order. This would, of course, be documented
above this_cpu_cmpxchg_double().
>
> > We could use a gcc builtin like the following to check if the alignment of
> > "percpu_dd" meets the double-cas requirements:
> >
> > #define testmacro(a, b) \
> > __builtin_choose_expr(__alignof__(a) >= 2 * sizeof(unsigned long), \
> > ((a).low) = (b), \ /* success */
> > ((a).low) = (void) 0) /* compile-error */
> >
> > > or
> > >
> > > this_cpu_cmpxchg_double(percpu_dd, old_dd, new_dd)
> > >
> > > with the problem of 128 bit constants/structs passed by value.
> >
> > Yeah, I guess trying to deal with 128-bit value might be a bit tricky. But
> > having something sane and with compile-time-checked alignment for the percpu_dd
> > type is not to be looked over.
>
> The existing implementation could be equipped to do a compile time check
> for the proper alignment if the pointer passed is constant.
"if the pointer passed is constant" -> if you use the actual type of percpu_dd
to check the alignment, then you can do an alignment check at compile-time even
for a non-const parameter. The requirement imposed on typing will take care to
make sure that even a non-const pointer will have the proper alignment.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2011-01-21 18:10 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 20:45 [cpuops cmpxchg double V2 0/4] this_cpu_cmpxchg_double support Christoph Lameter
2011-01-06 20:45 ` [cpuops cmpxchg double V2 1/4] Generic support for this_cpu_cmpxchg_double Christoph Lameter
2011-01-06 21:08 ` Mathieu Desnoyers
2011-01-06 21:43 ` Christoph Lameter
2011-01-06 22:05 ` H. Peter Anvin
2011-01-07 15:15 ` Christoph Lameter
2011-01-07 18:04 ` Mathieu Desnoyers
2011-01-07 18:41 ` Christoph Lameter
2011-01-08 17:24 ` Tejun Heo
2011-01-09 8:33 ` Pekka Enberg
2011-01-21 7:31 ` Pekka Enberg
2011-01-21 9:26 ` Tejun Heo
2011-01-21 15:31 ` H. Peter Anvin
2011-01-21 15:48 ` Tejun Heo
2011-01-21 16:30 ` H. Peter Anvin
2011-01-21 16:34 ` Tejun Heo
2011-01-21 16:54 ` Mathieu Desnoyers
2011-01-21 17:07 ` Christoph Lameter
2011-01-21 17:50 ` Mathieu Desnoyers
2011-01-21 18:06 ` Christoph Lameter
2011-01-21 18:37 ` Mathieu Desnoyers
2011-01-21 17:08 ` Tejun Heo
2011-01-21 17:13 ` H. Peter Anvin
2011-01-21 17:19 ` Tejun Heo
2011-01-24 6:01 ` H. Peter Anvin
2011-02-25 13:09 ` Pekka Enberg
2011-02-25 13:19 ` Tejun Heo
2011-02-25 16:26 ` Christoph Lameter
2011-02-25 16:37 ` Tejun Heo
2011-02-25 16:43 ` Christoph Lameter
2011-02-25 16:38 ` Eric Dumazet
2011-02-25 16:45 ` Christoph Lameter
2011-01-21 17:24 ` Christoph Lameter
2011-01-21 17:42 ` Mathieu Desnoyers
2011-01-21 17:50 ` Christoph Lameter
2011-01-21 18:10 ` Mathieu Desnoyers [this message]
2011-01-21 18:42 ` Christoph Lameter
2011-01-21 18:31 ` H. Peter Anvin
2011-01-21 18:46 ` Christoph Lameter
2011-01-21 19:32 ` Mathieu Desnoyers
2011-01-23 18:00 ` H. Peter Anvin
2011-01-06 20:45 ` [cpuops cmpxchg double V2 2/4] x86: this_cpu_cmpxchg_double() support Christoph Lameter
2011-01-06 20:45 ` [cpuops cmpxchg double V2 3/4] slub: Get rid of slab_free_hook_irq() Christoph Lameter
2011-01-06 20:45 ` [cpuops cmpxchg double V2 4/4] Lockless (and preemptless) fastpaths for slub Christoph Lameter
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=20110121181051.GC12150@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=eric.dumazet@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=tj@kernel.org \
/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.