Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1271741
| From | Byungchul Park <byungchul.park@lge.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once |
| Date | 2015-11-18 00:40 +0100 |
| Message-ID | <qvY0W-3hg-5@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <qtg41-4WH-1@gated-at.bofh.it> <qtqZr-3pr-7@gated-at.bofh.it> <qvry2-7qr-17@gated-at.bofh.it> <qvCD7-69M-7@gated-at.bofh.it> <qvMCu-4n1-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Nov 17, 2015 at 12:21:49PM +0100, Peter Zijlstra wrote: > > Looks that way, I'm not sure we always hold pi_lock there. But I'm low > on sleep, so I could have overlooked something. > > See for example move_queued_task(), we call set_task_cpu() with rq->lock > held, but no pi_lock. Indeed. > > > I thought the comment above migrate_task_rq_fair() is correct rather > > than CONFIG_LOCKDEP comment in set_task_cpu(), when I read it. I think > > these two comments are conflict each other a little bit, so one of > > those should be fixed. > > Agreed. Which one do you think to be fixed? The one above migrate_task_rq_fair()? I wonder if it would be ok even it does not hold pi_lock in migrate_task_rq_fair(). If you say *no problem*, I will try to fix the comment. > > I meant, if you call __set_task_cpu() before > sched_class::migrate_task_rq(), in that case task_rq_lock() will no > longer fully serialize against set_task_cpu(). > > Because once you've called __set_task_cpu(), task_rq_lock() will acquire > the _other_ rq->lock. And we cannot rely on our rq->lock to serialize > things. I agree with you if migtrate_task_rq() can be serialized by rq->lock without holding pi_lock. (even though I am still wondering..) But I thought it was no problem if migrate_task_rq() was serialized only by pi_lock as the comment above the migrate_task_rq() describes, because breaking rq->lock does not affect the sericalization by pi_lock. I would appreciate it if you would answer my questions. > -- > 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/ -- 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/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once Peter Zijlstra <peterz@infradead.org> - 2015-11-16 14:00 +0100
Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once Byungchul Park <byungchul.park@lge.com> - 2015-11-17 01:50 +0100
Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once Peter Zijlstra <peterz@infradead.org> - 2015-11-17 12:30 +0100
Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once Byungchul Park <byungchul.park@lge.com> - 2015-11-18 00:40 +0100
Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once Peter Zijlstra <peterz@infradead.org> - 2015-11-18 01:00 +0100
Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once Byungchul Park <byungchul.park@lge.com> - 2015-11-18 01:10 +0100
csiph-web