[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/2] x86/hpet: use an atomic add instead of a cmpxchg loop
On Thu, Feb 22, 2024 at 11:10:54AM +0100, Jan Beulich wrote: > On 22.02.2024 10:05, Roger Pau Monne wrote: > > 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). > > The code change looks good to me, but I fail to see the connection to > 2^32 CPUs. So it feels like I'm missing something, in which case I'd > rather not offer any R-b. The purpose of hpet_get_channel() is to distribute HPET channels across CPUs, so that each CPU gets assigned an HPET channel, balancing the number of CPUs that use each channel. This is done by (next_channel++ % num_hpets_used), so the value of next_channel after this change can be > num_hpets_used, which previously wasn't. This can lead to a different channel returned for the 2^32 call to the function, as the counter would overflow. Note calls to the function are restricted to the number of CPUs in the host, as per-CPU channel assignment is done only once (and the channel is then stored in a per-cpu variable). Feel free to adjust the commit message if you think all this is too much data, or too confusing. Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |