[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110106210846.GA3528@Krystal>
Date: Thu, 6 Jan 2011 16:08:46 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Christoph Lameter <cl@...ux.com>
Cc: Tejun Heo <tj@...nel.org>, akpm@...ux-foundation.org,
Pekka Enberg <penberg@...helsinki.fi>,
linux-kernel@...r.kernel.org,
Eric Dumazet <eric.dumazet@...il.com>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [cpuops cmpxchg double V2 1/4] Generic support for
this_cpu_cmpxchg_double
* Christoph Lameter (cl@...ux.com) wrote:
[...]
> + * cmpxchg_double replaces two adjacent scalars at once. The first two
> + * parameters are per cpu variables which have to be of the same size.
> + * A truth value is returned to indicate success or
> + * failure (since a double register result is difficult to handle).
> + * There is very limited hardware support for these operations. So only certain
> + * sizes may work.
What's the issue with returning the value read by cmpxchg_double in addition to
the boolean ? "returning" it per se might be an issue, but you could add 2 more
parameters to the macros that take the addresses of these outputs. Returning the
values read by cmpxchg instead of just the boolean result helps removing the
extra reads from cmpxchg loops, which is why I think it's a shame to just return
the boolean result.
Thoughts ?
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists