[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAOGi=dOxM8+CTwJv1=Wi9CMrdjfYU9vP1Uw4ibmK4yTw5eeeLg@mail.gmail.com>
Date: Sun, 6 Dec 2015 21:08:04 +0800
From: Ling Ma <ling.ma.program@...il.com>
To: Waiman Long <waiman.long@....com>
Cc: Peter Zijlstra <peterz@...radead.org>, mingo@...hat.com,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
Ling <ling.ml@...baba-inc.com>
Subject: Re: Improve spinlock performance by moving work to one core
Longman,
We further optimized the kernel spinlock in ali-spin-lock.patch
as attachment based on kernel 4.3.0-rc4.
Run thread.c in user space with kernel patch(ali-spin-lock.patch) on E5-2699v3,
compare with original spinlock:
The printed data indicates the performance in critical path is
improved by 1.91x (92715428576 cycles/ 48475891244 cycles),
perf top -d1 also tell us the spinlock cost time is reduced from 25% to 15%
All compared data is from the below operation in ali-spin-lock.patch:
+#if ORG_QUEUED_SPINLOCK
+ org_queued_spin_lock((struct qspinlock *)&pa.n->list_lock);
+ refill_fn(&pa);
+ org_queued_spin_unlock((struct qspinlock *)&pa.n->list_lock);
+#else
+ ali_spin_lock((struct alispinlock *)&pa.n->list_lock, refill_fn, &pa);
+#endif
and
+#if ORG_QUEUED_SPINLOCK
+ org_queued_spin_lock((struct qspinlock *)&pa.n->list_lock);
+ flusharray_fn(&pa);
+ org_queued_spin_unlock((struct qspinlock *)&pa.n->list_lock);
+#else
+ ali_spin_lock((struct alispinlock *)&pa.n->list_lock,
flusharray_fn, &pa);
+#endif
We will send the formal patch as a separate synchronization mechanism soon.
Appreciate your comments.
Thanks
Ling
2015-12-01 4:55 GMT+08:00 Waiman Long <waiman.long@....com>:
> On 11/30/2015 01:17 AM, Ling Ma wrote:
>>
>> Any comments, the patch is acceptable ?
>>
>> Thanks
>> Ling
>>
>>
> Ling,
>
> The core idea of your current patch hasn't changed from your previous
> patch.
>
> My comment is that you should not attempt to sell it as a replacement
> of the current spinlock mechanism. I just don't see that will happen
> given the change in API semantics. Also, I think there are probably
> cases that your patch cannot be applied. So treat it as a separate
> synchronization mechanism that can be useful in some scenarios.
>
> Cheers,
> Longman
>
Download attachment "lock_test.tar.bz2" of type "application/x-bzip2" (7447 bytes)
Powered by blists - more mailing lists