|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [PATCH 2/2] x86/hpet: use an atomic add instead of a cmpxchg loop
The usage of a cmpxchg loop in hpet_get_channel() is unnecessary, as the same
can be achieved with an atomic increment, which is both simpler to read, and
avoid any need for a loop.
Note there can be a small divergence in the channel returned if next_channel
overflows, but returned channel will always be in the [0, num_hpets_used)
range, and that's fine for the purpose of balancing HPET channels across CPUs.
This is also theoretical, as there's no system currently with 2^32 CPUs (as
long as next_channel is 32bit width).
Signed-of-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
---
xen/arch/x86/hpet.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
index d982b0f6b2c9..4777dc859d96 100644
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -458,11 +458,7 @@ static struct hpet_event_channel
*hpet_get_channel(unsigned int cpu)
if ( num_hpets_used >= nr_cpu_ids )
return &hpet_events[cpu];
- do {
- next = next_channel;
- if ( (i = next + 1) == num_hpets_used )
- i = 0;
- } while ( cmpxchg(&next_channel, next, i) != next );
+ next = arch_fetch_and_add(&next_channel, 1) % num_hpets_used;
/* try unused channel first */
for ( i = next; i < next + num_hpets_used; i++ )
--
2.43.0
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |