[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC 10/16] gic:vgic:gic-vgic: introduce non-atomic bitops



On Mon, 3 Dec 2018 14:33:08 +0200
Andrii Anisov <andrii.anisov@xxxxxxxxx> wrote:

Hi Andrii,

> On 29.11.18 14:14, Andre Przywara wrote:
> > Nah, please don't do this.  
> Sorry for making you crying looking at this code.
> It's terrible, I know. It's rather an idea.
> 
> > Can you show that atomic bit ops are a
> > problem? They shouldn't be expensive unless contended, also pretty
> > lightweight on small systems (single cluster).  
> Yep, but still it is a call to a function of 10 operations instead of 
> one `orr` for set_bit(). Taking in account a heavy usage of bitops in 
> the old vgic code, this should benefit latency.

Please be careful with any estimate on "cost" when just looking at the
number of instructions. The costly part in both operations is the
memory access, if that misses any caches, it can easily cost multiple
hundred cycles, then doing ten more register-only instructions before
or after doesn't really matter anymore.
Plus __set_bit would be a "ldr-orr-str" sequence, not just an orr, as
this would need to be a read-modify-write sequence. So the difference
is not too much.

Cheers,
Andre.

> > But if you really think this is useful, why not go with the Linux
> > way of using __set_bit to provide a non-atomic version?
> > This would have the big advantage that you can replace them on a
> > case-by-case base, which is much less risky than unconditionally
> > replacing every (even future!) usage in the whole file.  
> Whatever you prefer :)
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.