From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (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 7E6543D16FC for ; Mon, 27 Apr 2026 14:14:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777299278; cv=none; b=UA+T13ya0lpNnunP1i7p0QELUMmzDy3qYWI3lNPdzeBb3yBWe37z2PEowQkf2BEj0LpSZ7B7YPcpcF3yDSsYLMn7ki+NZlipYrmVK3sPWTy7ydlbofI/NxveKqTTN8pjv901gwP6gqBIBA9eIPdEx/DzgvyNye1+dWdBrYbVtsQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777299278; c=relaxed/simple; bh=7pfgC0OFpo4hH9q94IdzrBZZzdAldUhVVts4dZJ0IzY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=bqvkZ+4nbhKq50TohWqCMlQsJkxGZwSQL5O5LMzYPIYGsqLtkRu8G7pVplAavx+rw7QOWDAC5vfis7WLKWTraWQaS1jd/1XS+ltVnI5HtkOtKOUkNSkMM4skjQ0ARjc5u2dJDtDF8R9JP1N1m6Aya+0KJQfrljXw5scmVPBEe+0= 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=WfdcR/qB; arc=none smtp.client-ip=209.85.221.74 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="WfdcR/qB" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-43d721a4858so7038989f8f.1 for ; Mon, 27 Apr 2026 07:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777299275; x=1777904075; 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=KOY9fgWdFDp7gkAn6yDNTiManbjKUqC7ExhU7qOgPnw=; b=WfdcR/qB5/9YfhSA/iww9V8ZBC37L+hUx9jz4SRevhmUJISyyUaHas9Kh0hbwoY/fc 809TUEcGGy+Vx9IyxhnqZHfFD8MAn1/zVoGQNo9gJMAC1VKwHurWR+WWL5hr1hyjMLf+ VPpeP461wWUR7OGtMGUjo8AetkGFX7sMqAJua/2MTRROdAPOOu3/vd91TW7ksM/2hZqZ IsT7K7AERwfjKisLak5F5hnHSd1/UpdTWdbDGK0ffeiBwEAzzeZrf9g8zzv3TAViI0UH y5H9o40QUl11bXZZVF+ep0hXKxgCtzH1jL3kEAd1aaj57ac9UvlAIACBQFX+mLZuv49G KyGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777299275; x=1777904075; 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=KOY9fgWdFDp7gkAn6yDNTiManbjKUqC7ExhU7qOgPnw=; b=FsRA6wgDk1rYzJz2OJynQQIz4P0WHzx++AuGfQOJc7qThmewlnhT1BjKE7yvSgMWR9 3P+7jJlfoCWeIi5BJVFoDwhbhWIY30FhNx2MhCl9SXXCB50yzM8v9ryBBju3DANCZ5JY grSmYYn64eQpiavY2B+OwiWkiBiB6ColAnP57Fsss758A3v0+yQN2Bl3kzEW+MXHy8Xc 5Ta3/oMg69EF1XxKxkubJ85qJAHfssGgBsStBsYNCW+MS0N5NEqBvA3LXdZFWdW5pLNe /WLWdnoAaawpzwadCpiINJ5abUCXVyM2uVF08xQfSH+TSoYQfrtmitEZ+DPPyoQZesfc Jmgg== X-Forwarded-Encrypted: i=1; AFNElJ+So9wMHkqVVrvXXKGbhNQn94CCtdQZG4JqOSPbi/ThZW964JYdussDMPbFMPU4JOSLsXCOAPwuh6HH6Ws=@vger.kernel.org X-Gm-Message-State: AOJu0YwrM9TBOJrsGBiXD66f2mzYLwL9/AhLPN3E8vpX858BGgcMgtsI JbFczMmzMc1bN9NeWqdIhW1XBPBVra0ZVFS9nggsDZ+YEtIc1jsTLHoy5pVQD8HAfBN7M/9upVg t7Kcn+sZlhYORrA== X-Received: from wrbdl9.prod.google.com ([2002:a05:6000:b89:b0:439:bfc3:59cd]) (user=jpiecuch job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:2502:b0:43e:b0f8:c564 with SMTP id ffacd0b85a97d-43fe3dbd756mr64451520f8f.9.1777299274278; Mon, 27 Apr 2026 07:14:34 -0700 (PDT) Date: Mon, 27 Apr 2026 14:14:33 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260424092245.3212529-1-jpiecuch@google.com> X-Mailer: aerc 0.21.0-0-g5549850facc2 Message-ID: Subject: Re: [PATCH sched_ext/for-7.1-fixes] sched_ext: Call wakeup_preempt() in local_dsq_post_enq() From: Kuba Piecuch To: Tejun Heo , Kuba Piecuch Cc: Andrea Righi , Changwoo Min , David Vernet , , , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Hi Tejun, On Fri Apr 24, 2026 at 5:17 PM UTC, Tejun Heo wrote: > Hello, Kuba. > > On Fri, Apr 24, 2026 at 09:22:44AM +0000, Kuba Piecuch wrote: >> @@ -1408,11 +1407,19 @@ static void local_dsq_post_enq(struct scx_sched *sch, struct scx_dispatch_q *dsq >> if ((enq_flags & SCX_ENQ_PREEMPT) && p != rq->curr && >> rq->curr->sched_class == &ext_sched_class) { >> rq->curr->scx.slice = 0; >> - preempt = true; >> + resched_curr(rq); >> } >> >> - if (preempt || sched_class_above(&ext_sched_class, rq->curr->sched_class)) >> - resched_curr(rq); > > Hmm... I don't quite understand this part of the change. sched_class_above() > got separated out into its own case but why is it dropping resched_curr() on > SCX_ENQ_PREEMPT? In the SCX_ENQ_PREEMPT case we call resched_curr() where we previously set preempt = true. In the sched_class_above() case, wakeup_preempt() will call resched_curr() for us: void wakeup_preempt(struct rq *rq, struct task_struct *p, int flags) { [...] if (p->sched_class == rq->next_class) { rq->next_class->wakeup_preempt(rq, p, flags); } else if (sched_class_above(p->sched_class, rq->next_class)) { rq->next_class->wakeup_preempt(rq, p, flags); =====> resched_curr(rq); <===== rq->next_class = p->sched_class; } [...] } > >> + /* >> + * If @rq->next_class is currently idle, we need to bump it >> + * to &ext_sched_class using wakeup_preempt(). Otherwise, if we drop >> + * the rq lock later in the pick and an RT task wakes up on @rq, >> + * wakeup_preempt_idle() will be called during RT task wakeup and >> + * SCX won't have an opportunity to re-enqueue IMMED tasks from @rq's >> + * local DSQ. > > As this was really subtle, I think it warrants documenting all cases here. Yeah, I was trying to keep it concise. How about something like this: /* * Note that @rq's lock may be dropped between this enqueue and @p * actually getting on CPU. This gives higher-class tasks (e.g. RT) * an opportunity to wake up on @rq and prevent @p from running. * Here are some concrete examples: * * Example 1: * * We dispatch two tasks from a single ops.dispatch(): * - First, a local task to this CPU's local DSQ; * - Second, a local/remote task to a remote CPU's local DSQ. * We must drop the local rq lock in order to finish the second * dispatch. In that time, an RT task can wake up on the local rq. * * Example 2: * * We dispatch a local/remote task to a remote CPU's local DSQ. * We must drop the remote rq lock before the dispatched task can run, * which gives an RT task an opportunity to wake up on the remote rq. * * Both examples work the same if we replace dispatching with moving * the tasks from a user-created DSQ. * * We must detect these wakeups so that we can re-enqueue IMMED tasks * from @rq's local DSQ. scx_wakeup_preempt() serves exactly this * purpose, but for it to be invoked, we must ensure that we bump * @rq->next_class to &ext_sched_class if it's currently idle. * * wakeup_preempt() does the bumping, and since we only invoke it if * @rq->next_class is below &ext_sched_class, it will also * resched_curr(rq). */ Thanks, Kuba