From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 E70D824A06B for ; Mon, 12 Jan 2026 14:46:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768229164; cv=none; b=exz2KHOBMHbiB+gGA803dL1nS21QUKurHlc1jSBp/v1kfol7eEi1bhUe/ENTgUyDltG6dCN9qqL8WuqmDD/zhmVruSJU/ohVy68csFyqQ6vXm5oTmBmIzAd+fBYuakHKwZq7TQUQF3CR0GFhuAEAW7IitDREW8J35/TfMaDo6J4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768229164; c=relaxed/simple; bh=dsdgXsVp7QFpXPnkcdTuP+mP0xsPpA55ieZlX5usu4M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bZRREjDK2E5DpqZT/z9CDX9u3TKK5G7Xk6V0eAlj8Ekd/wxMVWKxEVirg8bMV8ZuHDmp+f7q39lhG1C6gy8PKSlbUKIYEGVSXb5Fum4x5eETN3ox+hQoEy1IcKjlhH8Qt1js57YPLr5uQoswMxH6rheMYPvbwbb0oNa0tYS4RYA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=hPYc9B5h; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=BPOOjVbY; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="hPYc9B5h"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="BPOOjVbY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768229161; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Oh9AW5ZoChp93cyv5LW/vvK1qwA8ELR3SCMoUe3Oxhg=; b=hPYc9B5h9kEQt2l9SYdfevcFF88CffSt2p7OGVGzVzsBcLVPtJ9dthZ1vEy85g+f+U4sIL RnqPedPH9KyOisQFaUINCqJXuESwNgQdT5251zJ/Mcrzoc1pPULJD10kRAymmtXhe+hFpT ZfsAEqamIk+zy4FFth8qFbs7goKdaS0= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-110-k2Z_k8bROtuerH9CQHi2Gg-1; Mon, 12 Jan 2026 09:46:00 -0500 X-MC-Unique: k2Z_k8bROtuerH9CQHi2Gg-1 X-Mimecast-MFC-AGG-ID: k2Z_k8bROtuerH9CQHi2Gg_1768229159 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4792bd2c290so75496695e9.1 for ; Mon, 12 Jan 2026 06:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768229159; x=1768833959; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Oh9AW5ZoChp93cyv5LW/vvK1qwA8ELR3SCMoUe3Oxhg=; b=BPOOjVbYpo65Emym6vsEtCkwuOSLRBqAVNIb7a8DWcGAOX+EoiXmcQmTAxsDbE8ZNA I+LkPT3y9easPwTVN5+sclgTst9ULmqXdzg1mrH88dFwJpD+ThjRbkSFwMCmeLcyg6oH MN4jvHVxyEADt5zcAvWM5psK3WylBXRDgh8UnCxINb+eeKR6PmtfqImLg09H7gM8RBpj 35p9HMJF2TcyB5JMXhnE5uWXuR8s2gkkLDFYAnuI7Tvna/kSut5asy8smb7Yt8HU5iMa Erx5g/uzgiFA9VRJm+m1QeE8DcTTUQjpDTW4GOwGp4f+aQEKD3UVSK62eWw6csVo87Wt M7RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768229159; x=1768833959; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Oh9AW5ZoChp93cyv5LW/vvK1qwA8ELR3SCMoUe3Oxhg=; b=jr51P9TAT792qPGVHPLSZ7t2bskam19WxndstiTaMuv26/DmdelIxDUMhLAbLry/Cl q6l0iXVEynrmW4RtifJtOg2mlRT+ngsdY9OCSpeJO582jqeP5mwCs7XFy+thafJHid0n qQU2cVCokrNjI7j1YRyRc1RQzOAVTKcb/jqjhKi4AQ2esbVslOmUTOXjG02Ey5jtDBof XEeHtQHOOT4naVEaPaOh63qZo6Ho+2k4Ud3bkpdxv36Eq7vg5JyJWp0rEYDEuRpDdJ5t Ic3s4xapINvVOh7G6LsGXV6b+iMQZoMI4tRio0Ok3/uf73k1YngmlpQ1TsGN306/VC11 tYgQ== X-Gm-Message-State: AOJu0YzTJPFnvfwV+FkmX7oa/22e5RYLdQR56RzEYQXTNnui0L+kUDCH WRC7bz6zo76YAPwYjUzikVVD77qJOReylUDKVCnIOegJw+tea2yGKMha1UM6f4253/VzFTOR3ld TTFcJBR11Gj+n4SR2o9KcTB5AbexLaXCTp8RdBLCaenFyfOx9YLOSr6ukx3JDAVFcmrTidumUFg == X-Gm-Gg: AY/fxX73+Kjf5H+TCWAPkojiXWLt58FLgMtW/TYagdgpI/Q5hjHSoWvXhvXdZhZq6Cf +qFhoLSD6xRU8mUNvJ/mOzFwJ/5qTYToO++GUcB5x0mQgyqOUxAfArPVV6n72x1XUUSPPQPbMDZ inSY8VNhqwuIqPwBqh+k0Y8kuAnq6P3HGnYPdaXyE7p9ab3ZrUyNK5nVptAOJkkEk34GCzYIeOv p7TixyhD6bxqSNkJhsjy13W10wtEwd4f53Tb3bjgQjgzDc+QByLgx1HMucYBmiSPPoZVHsekAPC me6ZV3sU7xxR38Ki5taA/ymHzkqr19mB+fCzkboILdVmQFNJwCpv94F3Rbh78p9UrJWZRSz7mJQ dm+1LFHRHO/5lopuI1SYM3ynS98mWTQobGKgf/ds2 X-Received: by 2002:a05:600c:1994:b0:47a:80f8:82ac with SMTP id 5b1f17b1804b1-47d84b39efcmr196678435e9.26.1768229158867; Mon, 12 Jan 2026 06:45:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IF5kl+ewBACQ0wm1lDyDKLxLXLl5PWgtPzfqXGehwwQRZ7onoUBYMueFzkpAhzkLyiLLXLDUQ== X-Received: by 2002:a05:600c:1994:b0:47a:80f8:82ac with SMTP id 5b1f17b1804b1-47d84b39efcmr196678215e9.26.1768229158494; Mon, 12 Jan 2026 06:45:58 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.129.40]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47d86372c92sm145497255e9.0.2026.01.12.06.45.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 06:45:57 -0800 (PST) Date: Mon, 12 Jan 2026 15:45:55 +0100 From: Juri Lelli To: Gabriele Monaco Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Juri Lelli , Clark Williams Subject: Re: sched/deadline: Server stops while fair tasks are still runnable Message-ID: References: <8394f68afac3b26aeba3def48d927e3ab7c177e3.camel@redhat.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: <8394f68afac3b26aeba3def48d927e3ab7c177e3.camel@redhat.com> Hi Gabriele, On 12/01/26 10:02, Gabriele Monaco wrote: > The boost model in [1] spotted cases with fair tasks running after the server > stopped. I believe this means that it's equally possible for those tasks to > starve without the server even trying to start. > > There are 2 related situation that can result in this: > > 1. dl_server_idle is set to true when the CPU is really idle > 2. a fair task wakes up (nothing happens since the server is still active) > 3. dl_server_timer stops the server since it's idle, although it isn't really > > ``` > -0 d.h3. 2.521220: event_boost: -12: idle x dl_replenish -> idle > -0 d.h3. 2.521227: event_laxity: -12: zero_laxity_wait x dl_replenish_idle -> idle_wait > thread3-3-580 d..4. 3.338067: event_boost: -12: idle x dl_server_resume_throttled -> throttled > thread3-3-580 d..3. 3.338076: sched_wakeup: ksoftirqd/12:118 [120] CPU:012 > thread5-5-582 d.h2. 3.471237: event_boost: -12: throttled x dl_server_stop -> stopped (final) > thread5-5-582 d.h2. 3.471240: event_laxity: -12: idle_wait x dl_server_stop -> stopped (final) > ktimers/12-117 d..3. 3.538088: error_boost: -12: event sched_switch_in not expected in the state stopped > ktimers/12-117 d..2. 3.538089: sched_switch: ktimers/12:117 [98] S ==> ksoftirqd/12:118 [120] > ``` > > > 1. dl_server_timer runs when the CPU is idle but after a fair task wakes up > 2. the call to update_curr sets dl_server_idle since it's only checking rq->curr > (which is indeed idle) > 3. the server is stopped within the same timer call although a fair task just > woke up > > ``` > ktimers/13-125 d.s52 7.309878: event_boost: -12: stopped x dl_server_start -> ready > ktimers/13-125 d.s52 7.309878: event_laxity: -12: stopped x dl_server_start -> zero_laxity_wait > ktimers/13-125 d.s42 7.309879: sched_wakeup: kworker/u519:2:5559 [120] CPU:012 > -0 d.h3. 7.309889: event_boost: -12: ready x dl_replenish -> ready > -0 d.h3. 7.309889: event_laxity: -12: zero_laxity_wait x dl_replenish_idle -> idle_wait > -0 d.h3. 7.309890: event_boost: -12: ready x dl_server_stop -> stopped (final) > -0 d.h3. 7.309891: event_laxity: -12: idle_wait x dl_server_stop -> stopped (final) > -0 d..3. 7.309895: error_boost: -12: event sched_switch_in not expected in the state stopped > -0 d..2. 7.309896: sched_switch: swapper/12:0 [120] R ==> kworker/u519:2:5559 [120] > > ``` > > In both cases, if no new fair task wakes up, the one that woke up right before > stopping the server could starve. That's a problem isn't it? Yeah, think so. :/ Looks like we clear dl_defer_idle only while updating the fair task entity (which didn't happen yet in both cases above). > I tried a quick solution to the first case by clearing dl_server_idle every time > the server started (even if it's still active, that is at every fair wakeup) and > I think the second case could be avoided by relying on idle_cpu() instead of > looking only on rq->curr, taking also waking tasks into account (not tried). Not sure if you want to wait for Peter to chime in, but if you have patches we can definitely take a look. :) Thanks, Juri