All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Tejun Heo <tj@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>,
	Christoph Lameter <cl@linux.com>,
	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 11:54:25 -0500	[thread overview]
Message-ID: <20110121165425.GB11687@Krystal> (raw)
In-Reply-To: <20110121154831.GE2832@htj.dyndns.org>

* Tejun Heo (tj@kernel.org) wrote:
> Hello, Peter.
> 
> On Fri, Jan 21, 2011 at 07:31:55AM -0800, H. Peter Anvin wrote:
> > I really object to passing two pointers where one of them has to be a
> > fixed offset to the other.  That really doesn't make any sense.
> 
> Yeah, I hear you, but it really comes down to which ugliness disgusts
> one the most.  That, unfortunately, is inherently very subjective when
> there's no significantly better choice.
> 
> For me, the double parameter thing at least seems to have the
> advantages of being able to verify the two intended memory locations
> to be used actually are together and looking ugly reflecting its true
> nature.
> 
> The inherent ugliness stems from the fact that we don't have the
> built-in data type to properly deal with this.  Array of length two
> might be better fit, but I can see as many downsides with that too.
> 
> So, if anyone can give something clearly better for technical reasons,
> I'll be more than happy to take it, but as it currently stands, it
> seems we'll have to choose one among uglies and not everyone would be
> happy about the choice.  :-(

Quoting Christoph, from the previous exchange:

"The single large 128 bit scalar does not work. Having to define an
additional structure it also a bit clumsy. I think its best to get another
patchset out that also duplicates the first parameter and makes the percpu
variable specs conform to the other this_cpu ops."

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

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;
}

So by keeping distinct variables for the oval/nal arguments, we let the compiler
use registers (instead of the mandatory stack use that would be required if we
pass union or structures as oval/nval arguments), but we ensure proper alignment
(and drop the unneeded second pointer, as well as the runtime pointer alignment
checks) by passing one single pcp pointer of a fixed type with a known
alignment.

Thoughts ?

Mathieu

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com

  parent reply	other threads:[~2011-01-21 16:54 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 [this message]
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
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=20110121165425.GB11687@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.