Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1699035
| From | Vikram Mulukutla <markivx@codeaurora.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync |
| Date | 2017-07-28 21:20 +0200 |
| Message-ID | <u8iXM-7RN-5@gated-at.bofh.it> (permalink) |
| References | <u7vkm-1ob-21@gated-at.bofh.it> <u7vkm-1ob-19@gated-at.bofh.it> <u7FWq-82k-11@gated-at.bofh.it> <u826D-5lO-25@gated-at.bofh.it> <u89KP-1TI-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2017-07-28 02:28, Peter Zijlstra wrote: > On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote: > >> I think we should have this discussion now - I brought this up earlier >> [1] >> and I promised a test case that I completely forgot about - but here >> it >> is (attached). Essentially a Big CPU in an acquire-check-release loop >> will have an unfair advantage over a little CPU concurrently >> attempting >> to acquire the same lock, in spite of the ticket implementation. If >> the Big >> CPU needs the little CPU to make forward progress : livelock. > > This needs to be fixed in hardware. There really isn't anything the > software can sanely do about it. > > It also doesn't have anything to do with the spinlock implementation. > Ticket or not, its a fundamental problem of LL/SC. Any situation where > we use atomics for fwd progress guarantees this can happen. > Agreed, it seems like trying to build a fair SW protocol over unfair HW. But if we can minimally change such loop constructs to address this (all instances I've seen so far use cpu_relax) it would save a lot of hours spent debugging these problems. Lot of b.L devices out there :-) It's also possible that such a workaround may help contention performance since the big CPU may have to wait for say a tick before breaking out of that loop (the non-livelock scenario where the entire loop isn't in a critical section). > The little core (or really any core) should hold on to the locked > cacheline for a while and not insta relinquish it. Giving it a chance > to > reach the SC. Thanks, Vikram -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Thomas Gleixner <tglx@linutronix.de> - 2017-07-26 16:20 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync qiaozhou <qiaozhou@asrmicro.com> - 2017-07-27 03:40 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Thomas Gleixner <tglx@linutronix.de> - 2017-07-27 17:20 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Will Deacon <will.deacon@arm.com> - 2017-07-27 17:20 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Vikram Mulukutla <markivx@codeaurora.org> - 2017-07-28 03:20 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Will Deacon <will.deacon@arm.com> - 2017-07-28 11:30 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Vikram Mulukutla <markivx@codeaurora.org> - 2017-07-28 21:10 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync qiaozhou <qiaozhou@asrmicro.com> - 2017-07-31 13:30 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Peter Zijlstra <peterz@infradead.org> - 2017-07-28 11:30 +0200
Re: [Question]: try to fix contention between expire_timers and try_to_del_timer_sync Vikram Mulukutla <markivx@codeaurora.org> - 2017-07-28 21:20 +0200
csiph-web