Re: [HACKERS] LWLock optimization for multicore Power machines

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: [HACKERS] LWLock optimization for multicore Power machines
Дата
Msg-id CAPpHfdvBwZnGrfVZb8dYb5v+pJjGOdvv3eMrBDDzKkjeLnShFw@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] LWLock optimization for multicore Power machines  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: [HACKERS] LWLock optimization for multicore Power machines
Список pgsql-hackers
On Thu, Apr 6, 2017 at 2:16 AM, Andres Freund <andres@anarazel.de> wrote:
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...

Thank you for your comments.
I didn't x86 benchmarking.  I even didn't manage to reproduce previous results on Power8.
Presumably, it's because previous benchmarks were done on bare metal, while now I have to some kind of virtual machine on IBM E880 where I can't reproduce any win of Power8 LWLock optimization.  But probably there is another reason.
Thus, I'm moving this patch to the next CF.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] GSOC'17 project introduction: Parallel COPY executionwith errors handling
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: [HACKERS] LWLock optimization for multicore Power machines