Message-ID: <56560691.8000702@hpe.com>
Date: Wed, 25 Nov 2015 14:05:53 -0500
From: Waiman Long <waiman.long@hpe.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130109 Thunderbird/10.0.12
MIME-Version: 1.0
To: Ling Ma <ling.ma.program@gmail.com>
CC: Peter Zijlstra <peterz@infradead.org>, mingo@redhat.com,
        linux-kernel@vger.kernel.org, Ling <ling.ml@alibaba-inc.com>
Subject: Re: Improve spinlock performance by moving work to one core
References: <CAOGi=dN6=iHUKyN=BcJ4dZkEyv5bA9amU1uCqD-hqaUJnY=Zug@mail.gmail.com> <563B8E85.6090104@hpe.com> <CAOGi=dPc0mpzVKiFKFrgi3qw6RSLaMpO5ZoKEY-7HjcAMHLMhg@mail.gmail.com> <563CE5A6.8080409@hpe.com> <CAOGi=dOLCQ4BtzpsSEO-XVepFbypvj7qJ4_d2=bcp4KYRKJ5RQ@mail.gmail.com>
In-Reply-To: <CAOGi=dOLCQ4BtzpsSEO-XVepFbypvj7qJ4_d2=bcp4KYRKJ5RQ@mail.gmail.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1470
Lines: 46

On 11/23/2015 04:41 AM, Ling Ma wrote:
> Hi Longman,
>
> Attachments include user space application thread.c and kernel patch
> spinlock-test.patch based on kernel 4.3.0-rc4
>
> we run thread.c with kernel patch, test original and new spinlock respectively,
> perf top -G indicates thread.c cause cache_alloc_refill and
> cache_flusharray functions to spend ~25% time on original spinlock,
> after introducing new spinlock in two functions, the cost time become ~22%.
>
> The printed data  also tell us the new spinlock improves performance
> by about 15%( 93841765576 / 81036259588) on E5-2699V3
>
> Appreciate your comments.
>
>

I saw that you make the following changes in the code:

static __always_inline void queued_spin_lock(struct qspinlock *lock)
{
u32 val;
-
+repeat:
val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
if (likely(val == 0))
return;
- queued_spin_lock_slowpath(lock, val);
+ goto repeat;
+ //queued_spin_lock_slowpath(lock, val);
}


This effectively changes the queued spinlock into an unfair byte lock.
Without a pause to moderate the cmpxchg() call, that is especially bad
for performance. Is the performance data above refers to the unfair byte
lock versus your new spinlock?

Cheers,
Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/