[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |