Re: LWLock optimization for multicore Power machines
От | Andres Freund |
---|---|
Тема | Re: LWLock optimization for multicore Power machines |
Дата | |
Msg-id | 20170405231640.mjj7eu7wt7pstgkp@alap3.anarazel.de обсуждение исходный текст |
Ответ на | [HACKERS] LWLock optimization for multicore Power machines (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: LWLock optimization for multicore Power machines
|
Список | pgsql-hackers |
Hi, On 2017-04-03 11:56:13 -0700, Andres Freund wrote: > > > +/* > > + * Generic implementation of pg_atomic_fetch_mask_add_u32() via loop > > + * of compare & exchange. > > + */ > > +static inline uint32 > > +pg_atomic_fetch_mask_add_u32_impl(volatile pg_atomic_uint32 *ptr, > > + uint32 mask_, uint32 add_) > > +{ > > + uint32 old_value; > > + > > + /* > > + * Read once outside the loop, later iterations will get the newer value > > + * via compare & exchange. > > + */ > > + old_value = pg_atomic_read_u32_impl(ptr); > > + > > + /* loop until we've determined whether we could make an increment or not */ > > + while (true) > > + { > > + uint32 desired_value; > > + bool free; > > + > > + desired_value = old_value; > > + free = (old_value & mask_) == 0; > > + if (free) > > + desired_value += add_; > > + > > + /* > > + * Attempt to swap in the value we are expecting. If we didn't see > > + * masked bits to be clear, that's just the old value. If we saw them > > + * as clear, we'll attempt to make an increment. The reason that we > > + * always swap in the value is that this doubles as a memory barrier. > > + * We could try to be smarter and only swap in values if we saw the > > + * maked bits as clear, but benchmark haven't shown it as beneficial > > + * so far. > > + * > > + * Retry if the value changed since we last looked at it. > > + */ > > + if (pg_atomic_compare_exchange_u32_impl(ptr, &old_value, desired_value)) > > + return old_value; > > + } > > + pg_unreachable(); > > +} > > +#endif > > Have you done x86 benchmarking? I think unless such benchmarking is done in the next 24h we need to move this patch to the next CF... Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: