Messages in this thread | | | Date | Fri, 21 Jan 2011 12:50:54 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [cpuops cmpxchg double V2 1/4] Generic support for this_cpu_cmpxchg_double |
| |
* Christoph Lameter (cl@linux.com) wrote: > On Fri, 21 Jan 2011, Mathieu Desnoyers wrote: > > > I'm again probably missing something, but what is "clumsy" about defining a > > structure like the following to ensure proper alignment of the target > > pointer (instead of adding a runtime test) ? > > > > struct cmpxchg_double { > > #if __BYTE_ORDER == __LITTLE_ENDIAN > > unsigned long low, high; > > #else > > unsigned long high, low; > > #endif > > } __attribute__((packed, aligned(2 * sizeof(unsigned long)))); > > > > (note: packed here along with "aligned" does _not_ generate ugly bytewise > > read/write memory ops like "packed" alone. The use of "packed" is to let the > > compiler down-align the structure to the value requested, instead of uselessly > > aligning it on 32-byte if it chooses to.) > > > > The prototype could then look like: > > > > bool __this_cpu_generic_cmpxchg_double(pcp, oval_low, oval_high, nval_low, nval_high); > > > > With: > > struct cmpxchg_double *pcp > > That does not conform to the parameter conventions in other this_cpu_ops. > The first parameter is a variable because the notion of a pointer is > problematic given that percpu operations use a segment prefix to relocate > pointers.
So the first argument could be along the lines of:
struct cmpxchg_double pcp
then.
> You would be implicitly passing a 128 bit argument although the > compiler may not need to generate code for that.
Sorry, I don't understand this last statement. Does it still apply if we pass pcp as I just proposed ? (without the pointer, with a __builtin_choose_expr check on __alignof__ of the pcp parameter)
> > > I think Christoph's point is that he wants to alias this with a pointer. Well, > > this can be done cleanly with: > > > > union { > > struct cmpxchg_double casdbl; > > struct { > > void *ptr; > > unsigned long cpuid_tid; > > } t; > > } > > There is no need for aliases with the existing implementation. > > How will the macro check the parameters now?
Well, my last proposal to check __alignof__ within a __builtin_choose_expr check wouldn't need this union actually, which would be much better I think.
> > > Thoughts ? > > Could you actually try to write a patch instead running through points > that we have discussed earlier?
I'm going back to the points that have been previously dismissed with a rather large degree of handwaving. ;) I'm OK with looking into the API and providing code snippets to show the basic implementation behind the ideas, but I unfortunately don't have the bandwidth to stop everything I'm currently working on and start working on double-cas patches. Sorry, I wish I could do more.
Thanks,
Mathieu
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
| |