From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7230C2D97A6 for ; Thu, 9 Apr 2026 13:30:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775741458; cv=none; b=FXWDXQom8dqq4mtarc9Qe6RjBoD2el2CntQJxfnWklN7gKANwLf9gk8Eov8Z8Y1WkDvo0IAkdD9YHn0r2fmy9wmkdNq8O8ARli9m1d0qptzuoZ6bD9xj/wD4LLhzyIpC/k5jJcCV0QkLlTa2OzwC4nrOTZ9RtA5qJTyfvwvsLLU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775741458; c=relaxed/simple; bh=1vDONnPtuQaFBjh4i3xh/2XJZrsnpctlRxF12knVafk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=I8C4JqxYPvBDXNMes8aF2tI2m/sV+jgBv4++NRtK6EsIeZs9ljWkDbdvzjJh8WOPk73jIz2mAVYKuUdNCMks26QpCr2APLBF+2xHo4WTqwS+WfFeCR8OWvDVTW/AhBowegcCFcvdYcSXakEQBXpmaovS5m8XP/385wWz5fPJwRw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Wgj6tJAc; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Wgj6tJAc" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-48895008a3eso5570265e9.3 for ; Thu, 09 Apr 2026 06:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1775741456; x=1776346256; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=Oqa4eqyQLNo9cEyi+LpJijgc0BsEYFeGV08vjeCpB0o=; b=Wgj6tJAcrk6FZMXT+DW58GdegeMqOsdmdbg1FM/4xDc22UtjFrpFgCxmG0SKpTt1vY tKdYtDo+gFXMmKTbKcgY6HavqQ/FEYg7ug3OnM9CCWB3Gx30gsraz9PvKdHQxbnXo5qq 7fdhBcYnsDsHQvZE0A1efrJTlIkQ0bz81IuOitAdK+DRYvQAT7lklqltxYSvZXbSawWZ MDsfScJNpX0hBhyoZl85S0u5Qeb62klHIQiZAbOGTZntC9fkGD1j7JZp+yw7rfIXxJav aRM5vwsj8v6xx+H7O1DEBqYSxE+8NdaCZXK6RSWXYIW0WjuSKSZVh9s09fAtIx0IJlNL /J+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775741456; x=1776346256; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Oqa4eqyQLNo9cEyi+LpJijgc0BsEYFeGV08vjeCpB0o=; b=CTRTFskGqKesNh9+FB5HiUJ3X1hX/laLNNys3bG5AkbD8ZM+rSFwgYEBCioDssqlnH ss0HGXDtG9xZN7HX57aqaV5pJ1gUOVYUTse4q01g3sDHm++LTpjJRx2KPO0nszkXOpQM vL4kbLMH+WUba8gx2mx/WVoRmTLyfhY7x6uZw8eF5vzmEmrFj/VVRTj8UVasryLmZpeJ laJ9fdzIo6vBChqviEHIoyNtvngD3F5ZhI+UK10vgr7JcLbVq7dAot3nvXIs58p7MLBH n4SjCOMczSJV9rPFnnLpBX9fu6WQPEol/uRHn6zVXZ5AoPYYGD7fY6BfZB5tfHbCCFUs vseQ== X-Forwarded-Encrypted: i=1; AJvYcCV0Cab07NyE+uqYUhHa6mFyUhD+fO3HfkV96bHVsiwAf2hwcpQTbtMKRTLaR0vaw4pmXVWsIQ7FeqljBrE=@vger.kernel.org X-Gm-Message-State: AOJu0YysXG3E6AsBBQdT5JuBoZZuIB9Uq43olHNQeRCd/P4yHigwa6ID oIpxIHMXOBr1pGvId1kGC+/aBIyb3DlpHf8glO0nvbB4/vZhQ5BWgQ6u3F1xF7CD0D36WYU52ir dP/vII3qFQ+KIkA== X-Received: from wmsk21-n2.prod.google.com ([2002:a05:600d:8495:20b0:488:cae8:3a9b]) (user=jpiecuch job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:c10b:b0:488:b043:5efd with SMTP id 5b1f17b1804b1-488b0436356mr174753795e9.13.1775741455713; Thu, 09 Apr 2026 06:30:55 -0700 (PDT) Date: Thu, 09 Apr 2026 13:30:55 +0000 In-Reply-To: <0e2cb8a7-31fd-423b-8660-11357c08dab8@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260408091821.91063-1-jpiecuch@google.com> <0e2cb8a7-31fd-423b-8660-11357c08dab8@arm.com> X-Mailer: aerc 0.21.0-0-g5549850facc2 Message-ID: Subject: Re: [PATCH sched_ext/for-7.1] sched_ext: Documentation: Add missing calls to quiescent(), runnable() From: Kuba Piecuch To: Christian Loehle , Kuba Piecuch , Andrea Righi Cc: Tejun Heo , David Vernet , Changwoo Min , Emil Tsalapatis , , Content-Type: text/plain; charset="UTF-8" On Thu Apr 9, 2026 at 9:46 AM UTC, Christian Loehle wrote: ... >>> >>> ops.init_task(); /* A new task is created */ >>> ops.enable(); /* Enable BPF scheduling for the task */ >>> >>> while (task in SCHED_EXT) { >>> if (task can migrate) >>> ops.select_cpu(); /* Called on wakeup (optimization) */ >>> >>> ops.runnable(); /* Task becomes ready to run */ >>> >>> while (task_is_runnable(task)) { >>> if (task is not in a DSQ || task->scx.slice == 0) { >>> ops.enqueue(); /* Task can be added to a DSQ */ >>> >>> /* Task property change (i.e., affinity, nice, etc.)? */ >>> if (sched_change(task)) { >>> ops.dequeue(); /* Exiting BPF scheduler custody */ >>> ops.quiescent(); >>> >>> /* Property change callback, e.g. ops.set_weight() */ >>> >>> ops.runnable(); >>> continue; >>> } >>> >>> /* Any usable CPU becomes available */ >>> >>> ops.dispatch(); /* Task is moved to a local DSQ */ >>> ops.dequeue(); /* Exiting BPF scheduler custody */ > Is this true here? Any dispatch followed by a dequeue? The comment next to ops.dispatch() says the task is moved to a local DSQ, so if we assume that, then I think it will always be followed by ops.dequeue(). Same if we move the task to the global DSQ. Of course, you could do something weird like dispatch the task to a user DSQ, in which case there won't be a dequeue and the task won't start running, but that's weird enough that I don't think we need to consider it. You could also have a property change racing with the dispatch which would make the dispatch fail and not be followed by a dequeue, but again, we need to draw the line somewhere. So, in other words, any _successful_ dispatch to a _terminal_ DSQ is always followed by a dequeue. Another case that isn't handled here is direct dispatch to a terminal DSQ from ops.enqueue(), where we don't get ops.dispatch() or ops.dequeue() and go straight to ops.running(). If any of the above cases should be handled in the pseudocode, I'd say it's this one. >>> } >>> >>> ops.running(); /* Task starts running on its assigned CPU */ >>> >>> while (task_is_runnable(task) && task->scx.slice > 0) { >>> ops.tick(); /* Called every 1/HZ seconds */ >>> >>> if (task->scx.slice == 0) >>> ops.dispatch(); /* task->scx.slice can be refilled */ >>> } >>> >>> ops.stopping(); /* Task stops running (time slice expires or wait) */ >>> } >>> >>> ops.quiescent(); /* Task releases its assigned CPU (wait) */ >>> } >>> >>> ops.disable(); /* Disable BPF scheduling for the task */ >>> ops.exit_task(); /* Task is destroyed */