| From: | Andres Freund <andres(at)anarazel(dot)de> | 
|---|---|
| To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> | 
| 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-05 23:16:40 | 
| Message-ID: | 20170405231640.mjj7eu7wt7pstgkp@alap3.anarazel.de | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2017-04-05 23:20:36 | Re: [COMMITTERS] pgsql: Collect and use multi-column dependency stats | 
| Previous Message | Andres Freund | 2017-04-05 23:14:53 | Re: [GENERAL] C++ port of Postgres |