Re: LWLock optimization for multicore Power machines - Mailing list pgsql-hackers

From Andres Freund
Subject Re: LWLock optimization for multicore Power machines
Date
Msg-id 20170405231640.mjj7eu7wt7pstgkp@alap3.anarazel.de
Whole thread Raw
In response to [HACKERS] LWLock optimization for multicore Power machines  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: LWLock optimization for multicore Power machines  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: [GENERAL] C++ port of Postgres
Next
From: David Rowley
Date:
Subject: Re: [COMMITTERS] pgsql: Collect and use multi-columndependency stats