On 02/02/2014 04:03 AM, Ingo Molnar wrote:
* Waiman Long wrote:
How about making the selection of MCS or ticket queuing either user
configurable or depending on the setting of NR_CPUS, NUMA, etc?
No!
There are lots of disadvantages to adding such CONFIG_NUMA Kconfig
variants for locking prim
On Sun, Feb 02, 2014 at 10:03:57AM +0100, Ingo Molnar wrote:
>
> * Waiman Long wrote:
>
> > How about making the selection of MCS or ticket queuing either user
> > configurable or depending on the setting of NR_CPUS, NUMA, etc?
>
> No!
>
> There are lots of disadvantages to adding such CONFIG
* Waiman Long wrote:
> How about making the selection of MCS or ticket queuing either user
> configurable or depending on the setting of NR_CPUS, NUMA, etc?
No!
There are lots of disadvantages to adding such CONFIG_NUMA Kconfig
variants for locking primitives:
- an doubling of the test mat
On Fri, Jan 31, 2014 at 11:17:29AM +0100, Peter Zijlstra wrote:
> On Fri, Jan 31, 2014 at 05:03:48AM -0500, George Spelvin wrote:
> > How about getting rid of that TICKET_MSB mess and doing something like:
> >
> > #define TICKET_MASK 0x
> >
> > static inline void ticket_spin_unlock(atomic_t *
Peter Zijlstra wrote:
> On Fri, Jan 31, 2014 at 01:59:02PM -0500, Waiman Long wrote:
>> Using a ticket lock instead will have the same scalability problem as the
>> ticket spinlock as all the waiting threads will spin on the lock cacheline
>> causing a lot of cache bouncing traffic. That is the rea
On Fri, 2014-01-31 at 16:09 -0500, Waiman Long wrote:
> On 01/31/2014 03:14 PM, Peter Zijlstra wrote:
> > On Fri, Jan 31, 2014 at 01:59:02PM -0500, Waiman Long wrote:
> >> On 01/31/2014 04:26 AM, Peter Zijlstra wrote:
> >>> On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
> The
On 01/31/2014 03:14 PM, Peter Zijlstra wrote:
On Fri, Jan 31, 2014 at 01:59:02PM -0500, Waiman Long wrote:
On 01/31/2014 04:26 AM, Peter Zijlstra wrote:
On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
The below is still small and actually works.
OK, so having actually worked t
On Fri, Jan 31, 2014 at 01:59:02PM -0500, Waiman Long wrote:
> On 01/31/2014 04:26 AM, Peter Zijlstra wrote:
> >On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
> >>The below is still small and actually works.
> >OK, so having actually worked through the thing; I realized we can
> >a
On Fri, Jan 31, 2014 at 01:59:02PM -0500, Waiman Long wrote:
> On 01/31/2014 04:26 AM, Peter Zijlstra wrote:
> >On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
> >>The below is still small and actually works.
> >OK, so having actually worked through the thing; I realized we can
> >a
On 01/31/2014 04:26 AM, Peter Zijlstra wrote:
On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
The below is still small and actually works.
OK, so having actually worked through the thing; I realized we can
actually do a version without MCS lock and instead use a ticket lock for
On Fri, Jan 31, 2014 at 11:17:29AM +0100, Peter Zijlstra wrote:
> My main point was that we should seriously look at a ticket lock instead
> of the MCS one, because while the MCS has better contention behaviour,
> we shouldn't optimize locks for the worst contention.
In fact, I should have just us
On Fri, Jan 31, 2014 at 05:03:48AM -0500, George Spelvin wrote:
> How about getting rid of that TICKET_MSB mess and doing something like:
>
> #define TICKET_MASK 0x
>
> static inline void ticket_spin_unlock(atomic_t *tickets)
> {
> u32 t = *tickets;
>
> smp_mb__before_atomic_in
How about getting rid of that TICKET_MSB mess and doing something like:
#define TICKET_MASK 0x
static inline void ticket_spin_unlock(atomic_t *tickets)
{
u32 t = *tickets;
smp_mb__before_atomic_inc();
/* Increment the low 16 bits without affecting the upper. */
On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
> The below is still small and actually works.
OK, so having actually worked through the thing; I realized we can
actually do a version without MCS lock and instead use a ticket lock for
the waitqueue.
This is both smaller (back to 8
On Thu, Jan 30, 2014 at 06:11:36PM +, Will Deacon wrote:
> On Thu, Jan 30, 2014 at 06:05:33PM +, Peter Zijlstra wrote:
> > On Thu, Jan 30, 2014 at 05:52:12PM +, Will Deacon wrote:
> > > It would be nice if these were default implementations of the unlock, then
> > > architectures just i
On Thu, Jan 30, 2014 at 06:05:33PM +, Peter Zijlstra wrote:
> On Thu, Jan 30, 2014 at 05:52:12PM +, Will Deacon wrote:
> > It would be nice if these were default implementations of the unlock, then
> > architectures just implement atomic_sub_release how they like.
>
> Yes, I suppose that m
On Thu, Jan 30, 2014 at 05:52:12PM +, Will Deacon wrote:
> It would be nice if these were default implementations of the unlock, then
> architectures just implement atomic_sub_release how they like.
Yes, I suppose that makes sense. Last time I proposed the primitive
nobody yelled at me, so I s
Hi Peter,
On Thu, Jan 30, 2014 at 03:44:00PM +, Peter Zijlstra wrote:
> Something like this would work for ARM and PPC, although I didn't do the
> PPC variant of atomic_sub_release().
>
>
> --- a/arch/arm64/include/asm/atomic.h
> +++ b/arch/arm64/include/asm/atomic.h
> @@ -90,6 +90,21 @@ sta
On Thu, Jan 30, 2014 at 10:50:41AM -0500, Waiman Long wrote:
> One more thing, I often see line like
>
> #define queue_write_unlock queue_write_unlock
>
> So exactly what effect does this macro have?
Makes sure the below doesn't emit another version.
#ifndef queue_write_unlock
/**
* queue_writ
On 01/30/2014 10:43 AM, Waiman Long wrote:
On 01/30/2014 10:17 AM, Peter Zijlstra wrote:
On Thu, Jan 30, 2014 at 02:04:53PM +0100, Peter Zijlstra wrote:
So I took out that ugly union and rewrote the code to be mostly
atomic_*(), gcc generates acceptable code and its smaller too.
824
On Thu, Jan 30, 2014 at 04:17:15PM +0100, Peter Zijlstra wrote:
> --- /dev/null
> +++ b/arch/x86/include/asm/qrwlock.h
> @@ -0,0 +1,18 @@
> +#ifndef _ASM_X86_QRWLOCK_H
> +#define _ASM_X86_QRWLOCK_H
> +
> +#include
> +
> +#if !defined(CONFIG_X86_OOSTORE) && !defined(CONFIG_X86_PPRO_FENCE)
> +#defin
On 01/30/2014 10:17 AM, Peter Zijlstra wrote:
On Thu, Jan 30, 2014 at 02:04:53PM +0100, Peter Zijlstra wrote:
So I took out that ugly union and rewrote the code to be mostly
atomic_*(), gcc generates acceptable code and its smaller too.
824 0 0 824 338
defconfig-build/
On Thu, Jan 30, 2014 at 02:04:53PM +0100, Peter Zijlstra wrote:
>
> So I took out that ugly union and rewrote the code to be mostly
> atomic_*(), gcc generates acceptable code and its smaller too.
>
> 824 0 0 824 338
> defconfig-build/kernel/locking/qrwlock.o
> 776
So I took out that ugly union and rewrote the code to be mostly
atomic_*(), gcc generates acceptable code and its smaller too.
824 0 0 824 338 defconfig-build/kernel/locking/qrwlock.o
776 0 0 776 308 defconfig-build/kernel/locking/qrwlock.o
I don't
v10->v11:
- Insert appropriate smp_mb__{before,after}_atomic_* calls to make sure
that the lock and unlock functions provide the proper memory barrier.
v9->v10:
- Eliminate the temporary smp_load_acquire()/smp_store_release() macros
by merging v9 patch 4 into patch 1.
- Include & remove
25 matches
Mail list logo
