From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4811156968 for ; Tue, 7 Jan 2025 21:20:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736284859; cv=none; b=MlLjcgOsNSTELN6AXGqHhbw49MVy7CB5e4D/NRICShJKyrNR/Ae3mabcLaOFobskPr+jfiBB1JEd2CkTd3NrSpI880QypCtraPqe9N+0+a53ry8TC2tt6rK6QGVFPktuYfyA7VXgwOe1oucq7JK94UQz60Fh4LkHv5Rqtqnz4Zg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736284859; c=relaxed/simple; bh=hjYNV4cJLydetn/IGn+AFXDgUFI4xrc2pKf/BFdTvS0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fQFlIRYon7SJKBojYRi9cjrGKgt2Ygjvie989Kuv+TnKCnd23IQJ/zV/vjHCCCHhhydNcx11+/DHNuXdCfCqfwqcXHbA66refZzi4+3IoAgA22YKi1EIotnXMQHoWOW3w3R1w5ihHBjqXPRHWB8IyXfpSnBdQ6fcqzVkGUrtlxc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uNGRIlsH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uNGRIlsH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 520EDC4CED6; Tue, 7 Jan 2025 21:20:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736284859; bh=hjYNV4cJLydetn/IGn+AFXDgUFI4xrc2pKf/BFdTvS0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uNGRIlsHyQ2K6XUsv3gyLvQCVhg49IuYrzepMCXtYQDHERQkGmsxbDohBzCcHjHlA 3PBNEO9+b7BzxPbL4afjq70DMRkFjD91yq6K/d5y4pYpkPTKrU7UkFny6Rc4+YGWKf Ru3RHHgSBkqS0GxlZUG+IRiELUlPPbbvAOBtVe7Y1v/txqo7eZNLOpNv4o1O/0yoBR fyF2QUkbb2NsMKfP8txHKSEbWUl+ETCubpiAN4G0fZAlhZMucLjO4/BwL2sowNKyff X0rceQ0d+8vwEgJGY/S2uGxk2tOBoSHyapAgk2N8/mGkr8+46/ussCgax6AVaug+/4 B2x7vzSHn16Mg== Date: Tue, 7 Jan 2025 11:20:58 -1000 From: Tejun Heo To: Henry Huang Cc: void@manifault.com, =?utf-8?B?6LCI6Ym06ZSL?= , "Yan Yan(cailing)" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1] sched_ext: keep running prev when prev->scx.slice != 0 Message-ID: References: <20250107042555.67051-1-henry.hj@antgroup.com> <20250107042555.67051-2-henry.hj@antgroup.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250107042555.67051-2-henry.hj@antgroup.com> Hello, On Tue, Jan 07, 2025 at 12:25:55PM +0800, Henry Huang wrote: > When %SCX_OPS_ENQ_LAST is set and prev->scx.slice != 0, > @prev will be dispacthed into the local DSQ in put_prev_task_scx(). > However, pick_task_scx() is executed before put_prev_task_scx(), > so it will not pick @prev. > Set %SCX_RQ_BAL_KEEP in balance_one() to ensure that pick_task_scx() > can pick @prev. > > Signed-off-by: Henry Huang > --- > kernel/sched/ext.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c > index 81da76a..5f6eb45 100644 > --- a/kernel/sched/ext.c > +++ b/kernel/sched/ext.c > @@ -2837,10 +2837,15 @@ static int balance_one(struct rq *rq, struct task_struct *prev) > /* > * Didn't find another task to run. Keep running @prev unless > * %SCX_OPS_ENQ_LAST is in effect. > + * > + * If %SCX_OPS_ENQ_LAST is set and prev->scx.slice != 0 (configured in ops.dispatch()), > + * @prev would be dispatched into the local DSQ in put_prev_task_scx() > + * (excuted after pick_task_scx()). Set %SCX_RQ_BAL_KEEP to ensure that @prev > + * would be picked in pick_task_scx() > */ > if ((prev->scx.flags & SCX_TASK_QUEUED) && > (!static_branch_unlikely(&scx_ops_enq_last) || > - scx_rq_bypassing(rq))) { > + scx_rq_bypassing(rq) || prev->scx.slice)) { Update current->scx.slice from ops.dispatch() is the recommended way of extending the current execution and the current behavior is just buggy especially when scx_ops_enq_last is set. While the above change fixes the case where ops.dispatch() updates current->scx.slice without dispatching any task, it's still theoretically wrong in that if ops.dispatch() updates current->scx.slice and dispatches tasks, we should keep running current before moving onto other tasks. To fix this properly, I think what should be done is adding something like the following. (untested and we probably should cache SCX_TASK_QUEUED testing result). Can you test whether the following fixes the issues you're seeing and if so update the patch accordingly? diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c index 19d2699cf638..48deb5d5510e 100644 --- a/kernel/sched/ext.c +++ b/kernel/sched/ext.c @@ -2813,6 +2813,10 @@ static int balance_one(struct rq *rq, struct task_struct *prev) flush_dispatch_buf(rq); + if ((prev->scx.flags & SCX_TASK_QUEUED) && prev->scx.slice) { + rq->scx.flags |= SCX_RQ_BAL_KEEP; + goto has_tasks; + } if (rq->scx.local_dsq.nr) goto has_tasks; if (consume_global_dsq(rq)) Thanks. -- tejun