Message ID | 1530519116-13103-1-git-send-email-kemi.wang@intel.com |
---|---|
Headers | show |
Series | Add a new mutex type PTHREAD_MUTEX_QUEUESPINNER_NP | expand |
On 07/02/2018 04:11 AM, Kemi Wang wrote: > The pthread adaptive mutex is designed based-on the truth that the lock > probably would be released after a few of CPU cycles in most cases. > Especially for the case: the applications code is well-behaved with a short > critical section that is highly contended. Thus, spinning on the lock for > a while instead of calling into the kernel to block immediately can help > to improve the system performance. This patch set is going to take a while to review. We are currently freezing the ABI/API for glibc 2.28 release on August 1st. Are you OK if we delay the inclusion of this feature to 2.29 once master reopens?
On 2018年07月06日 04:12, Carlos O'Donell wrote: > On 07/02/2018 04:11 AM, Kemi Wang wrote: >> The pthread adaptive mutex is designed based-on the truth that the lock >> probably would be released after a few of CPU cycles in most cases. >> Especially for the case: the applications code is well-behaved with a short >> critical section that is highly contended. Thus, spinning on the lock for >> a while instead of calling into the kernel to block immediately can help >> to improve the system performance. > > This patch set is going to take a while to review. > Yes. Thanks for taking your time to review! > We are currently freezing the ABI/API for glibc 2.28 release on August 1st. > I know. This patch series introduces a new mutex type and would not break the existed ABI/API. > Are you OK if we delay the inclusion of this feature to 2.29 once master > reopens? I hope we can pick this feature before 2.28 release if you are comfortable. The new mutex type would benefit some guys who have severe lock contention in their applications (Actually, some of our customers have complained to us). And we can keep improving this feature after 2.28 release later. >
On 2018年07月06日 09:32, kemi wrote: > > > On 2018年07月06日 04:12, Carlos O'Donell wrote: >> On 07/02/2018 04:11 AM, Kemi Wang wrote: >>> The pthread adaptive mutex is designed based-on the truth that the lock >>> probably would be released after a few of CPU cycles in most cases. >>> Especially for the case: the applications code is well-behaved with a short >>> critical section that is highly contended. Thus, spinning on the lock for >>> a while instead of calling into the kernel to block immediately can help >>> to improve the system performance. >> >> This patch set is going to take a while to review. >> > BTW, I can separate 1/4 patch into several sub-patches if you think it would be easier for review:) > Yes. Thanks for taking your time to review! > >> We are currently freezing the ABI/API for glibc 2.28 release on August 1st. >> > > I know. This patch series introduces a new mutex type and would not break the > existed ABI/API. > > >> Are you OK if we delay the inclusion of this feature to 2.29 once master >> reopens? > > I hope we can pick this feature before 2.28 release if you are comfortable. > > The new mutex type would benefit some guys who have severe lock contention in > their applications (Actually, some of our customers have complained to us). And > we can keep improving this feature after 2.28 release later. > >>
On 07/05/2018 09:32 PM, kemi wrote: > > > On 2018年07月06日 04:12, Carlos O'Donell wrote: >> On 07/02/2018 04:11 AM, Kemi Wang wrote: >>> The pthread adaptive mutex is designed based-on the truth that the lock >>> probably would be released after a few of CPU cycles in most cases. >>> Especially for the case: the applications code is well-behaved with a short >>> critical section that is highly contended. Thus, spinning on the lock for >>> a while instead of calling into the kernel to block immediately can help >>> to improve the system performance. >> >> This patch set is going to take a while to review. >> > > Yes. Thanks for taking your time to review! > >> We are currently freezing the ABI/API for glibc 2.28 release on August 1st. >> > > I know. This patch series introduces a new mutex type and would not break the > existed ABI/API. You don't break the ABI, but you do change it with the addition of a constant PTHREAD_MUTEX_QUEUESPINNER_NP in the public pthread.h headers. In theory this makes it OK for backport to the various distributions, since the constant addition is not tied to any versioned symbol and is simply a flag that you pass into the existing implementation. Your program has to be able to handle failure if you request this type and don't get it. >> Are you OK if we delay the inclusion of this feature to 2.29 once master >> reopens? > > I hope we can pick this feature before 2.28 release if you are comfortable. It's very unlikely to happen. I wand to set that expectation up front. We have only 3 weeks to get through the other issues that have been waiting longer in the queue than this, namely Intel CET, C11 threads, etc, everything you see here: https://sourceware.org/glibc/wiki/Release/2.28#Planning > The new mutex type would benefit some guys who have severe lock contention in > their applications (Actually, some of our customers have complained to us). And > we can keep improving this feature after 2.28 release later. Given that distributions could backport this (no new symbols, just a new flag), is there really any rush in getting it reviewed?
> It's very unlikely to happen. I wand to set that expectation up front. All right. > We have only 3 weeks to get through the other issues that have been waiting longer in the queue than this, namely Intel CET, C11 threads, etc, everything you see here: >https://sourceware.org/glibc/wiki/Release/2.28#Planning OK. Could you take a look at another patch series (read only while spinning) which is simpler and has been updated to V7. Thanks in advance. https://sourceware.org/ml/libc-alpha/2018-07/msg00164.html https://sourceware.org/ml/libc-alpha/2018-07/msg00163.html > Given that distributions could backport this (no new symbols, just a new flag), is there really any rush in getting it reviewed? To be honest, yes, please. And I will respond your feedback ASAP.
On 07/06/2018 11:56 AM, Wang, Kemi wrote: >> Given that distributions could backport this (no new symbols, just >> a new flag), is there really any rush in getting it reviewed? > > To be honest, yes, please. And I will respond your feedback ASAP. This sounds mysterious. Why are you in a rush?