Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1284852
| From | Ling Ma <ling.ma.program@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Improve spinlock performance by moving work to one core |
| Date | 2015-12-06 14:10 +0100 |
| Message-ID | <qCHeF-7kf-3@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <qyNC2-1Wc-15@gated-at.bofh.it> <qyVJf-7nu-3@gated-at.bofh.it> <qz0IW-35e-15@gated-at.bofh.it> <qApYC-8mg-11@gated-at.bofh.it> <qADIf-8wf-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
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@hpe.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 >
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: Improve spinlock performance by moving work to one core Waiman Long <waiman.long@hpe.com> - 2015-11-30 22:00 +0100 Re: Improve spinlock performance by moving work to one core Ling Ma <ling.ma.program@gmail.com> - 2015-12-06 14:10 +0100
csiph-web