From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: LWLock optimization for multicore Power machines |
Date: | 2017-04-06 14:37:25 |
Message-ID: | CAPpHfdvBwZnGrfVZb8dYb5v+pJjGOdvv3eMrBDDzKkjeLnShFw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 6, 2017 at 2:16 AM, Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2017-04-06 14:38:48 | Re: LWLock optimization for multicore Power machines |
Previous Message | Alexander Korotkov | 2017-04-06 13:47:46 | Re: GSOC'17 project introduction: Parallel COPY execution with errors handling |