From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934632AbcIPMQg (ORCPT ); Fri, 16 Sep 2016 08:16:36 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:44583 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757058AbcIPMQc (ORCPT ); Fri, 16 Sep 2016 08:16:32 -0400 Date: Fri, 16 Sep 2016 14:16:26 +0200 From: Peter Zijlstra To: Vincent Guittot Cc: Ingo Molnar , linux-kernel , Yuyang Du , Morten Rasmussen , Linaro Kernel Mailman List , Dietmar Eggemann , Paul Turner , Benjamin Segall Subject: Re: [PATCH 7/7 v3] sched: fix wrong utilization accounting when switching to fair class Message-ID: <20160916121626.GN5012@twins.programming.kicks-ass.net> References: <1473666472-13749-1-git-send-email-vincent.guittot@linaro.org> <1473666472-13749-8-git-send-email-vincent.guittot@linaro.org> <20160915131807.GS5008@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 15, 2016 at 05:36:58PM +0200, Vincent Guittot wrote: > On 15 September 2016 at 15:18, Peter Zijlstra wrote: > > On Mon, Sep 12, 2016 at 09:47:52AM +0200, Vincent Guittot wrote: > >> Update the sequence to follow the right one: > >> -dequeue task > >> -put task > >> -change the property > >> -enqueue task > >> -set task as current task > > > > But enqueue_entity depends on cfs_rq->curr, which is set by > > set_curr_task_fair(). > > With this sequence, cfs_rq->curr is null and the cfs_rq is "idle" as > the entity has been dequeued and put back in the rb tree the time to > change the properties. > > enqueue_entity use cfs_rq->cur == se for: > - updating current. With this sequence, current is now null so nothing to do > - to skip the enqueue of the se in rb tree. With this sequence, se is > put in the rb tree during the enqueue and take back during the set > task as current task > > I don't see any functional issue but we are not doing the same step > with the new sequence So I think you're right in that it should work. I also think we can then simplify enqueue_entity() in that it will never be possible to enqueue current with your change. But my brain just isn't working today, so who knows. > > Also, the normalize comment in dequeue_entity() worries me, 'someone' > > didn't update that when he moved update_min_vruntime() around. I now worry more, so we do: dequeue_task := dequeue_task_fair (p == current) dequeue_entity update_curr() update_min_vruntime() vruntime -= min_vruntime update_min_vruntime() // use cfs_rq->curr, which we just normalized ! put_prev_task := put_prev_task_fair put_prev_entity cfs_rq->curr = NULL; Now the point of the latter update_min_vruntime() is to advance min_vruntime when the task we removed was the one holding it back. However, it means that if we do dequeue+enqueue, we're further in the future (ie. we get penalized). So I'm inclined to simply remove the (2nd) update_min_vruntime() call. But as said above, my brain isn't co-operating much today.