From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: =?utf-8?q?=5BPATCH_v3_1/2=5D_x86=3A_simplify_non?= =?utf-8?q?=E2=80=91atomic_bitops?= Date: Thu, 26 Mar 2015 09:54:37 +0000 Message-ID: <5513D75D.3080602@citrix.com> References: <550C4120020000780006C14E@mail.emea.novell.com> <550C4279020000780006C16B@mail.emea.novell.com> <5512F533.8010600@citrix.com> <5513CABE020000780006DC0B@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Yb4dk-0005Ux-04 for xen-devel@lists.xenproject.org; Thu, 26 Mar 2015 10:03:52 +0000 In-Reply-To: <5513CABE020000780006DC0B@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 26/03/15 08:00, Jan Beulich wrote: >>>> On 25.03.15 at 18:49, wrote: >> On 20/03/15 14:53, Jan Beulich wrote: >>> - being non-atomic, their pointer arguments shouldn't be volatile- >>> qualified >>> - their (half fake) memory operands can be a single "+m" instead of >>> being both an output and an input >>> >>> Signed-off-by: Jan Beulich >> After further consideration, would it not be better to change the >> non-atomic variants to being straight C. >> >> e.g. >> >> static inline void __set_bit(int nr, void *_addr) >> { >> int *addr = _addr; >> addr[nr / sizeof(int)] |= (1U << (nr % sizeof(int))); >> } >> >> This would drop the memory clobber from the asm statement and allow the >> compiler to optimise repeated __set_bit() calls to the same word into a >> single action. > I wouldn't want to do this in this patch - a similar change that I > proposed years ago for Linux (not eliminating the asm(), but > dropping the clobbers) caused not really understood regressions and > hence needed to be reverted. Presumably some code was lacking barrier()s > We could still try whether this works in > Xen, but in another patch. Apart from that I doubt the operation > above would reliably get converted to BTS by the compiler > (independent of version). Ok - lets leave that for v2. Both patches Reviewed-by: Andrew Cooper > >> (On a separate note, I feel that all of these operations should be >> acting on unsigned rather than signed ints, but that applies to all of >> these operations, not just the non-atomic ones) > That makes zero difference for these ops - all that really matters > is the width. In the C version above however I agree that using > "unsigned int" would be more natural. > > Jan >