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.129.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 65A662F83A7 for ; Fri, 30 Jan 2026 07:30:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769758243; cv=none; b=OHfw/ruyqcVdYEoUiUY5V/FRfgzYvKf1fWjBeEUHF8vL++Uez8hN6oWeCSbNFstNhKERjsEaGWI63xHz2UtW8UvnPAFywvlsJ4OnzRFEJm75pXcloZhxc+b00wek8tkQqqleg2Ds1+epD7WL8S4ZfqgE3NdZAfixbDesL1MG0N4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769758243; c=relaxed/simple; bh=IhojoqEXBqkzSwxMMuMzsBqB/OpLdz62qyHC18CuT/0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mu/gB3wDl+EXiahnN5TArm+8B43OcYWkwOK6E8+LPa0rnil2NCz8Hax8oQF+Uy/D82KJoBFodV9BeA/O2+8A+tw/zNalzXFMYqeejC+RAOkye4WYPqFECKtthbaPq9ll7ZpZQW9qZjC05rUgMRpeLNRvlH6AfmltX55pIRGcEwc= 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=SI/7Ow8K; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=T6V8tpfz; arc=none smtp.client-ip=170.10.129.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="SI/7Ow8K"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="T6V8tpfz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769758240; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vXE39MMsimPhoKoNy3Yqix7G7FwLtMlrZ2auUPwP+5M=; b=SI/7Ow8KJfl2J6t6iST3qfWLzbGeQph8bgaX4AGTf18IjADPe+EtNuWxtFSOuGLVfEqxJ/ 2dQUFnPKDv5ZYJQtzQUHFts2BE0Nfyx3j6ncphPgFvJCbR+3bUB2CfvoBWbgcr8dtauP3a zzdQzV/+JCNztm0zRIBK/39v9EWBPyQ= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-169-MkUBY8XIO8GV2ajVYinuWA-1; Fri, 30 Jan 2026 02:30:35 -0500 X-MC-Unique: MkUBY8XIO8GV2ajVYinuWA-1 X-Mimecast-MFC-AGG-ID: MkUBY8XIO8GV2ajVYinuWA_1769758235 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-435991d4a3aso982775f8f.1 for ; Thu, 29 Jan 2026 23:30:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769758234; x=1770363034; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=vXE39MMsimPhoKoNy3Yqix7G7FwLtMlrZ2auUPwP+5M=; b=T6V8tpfz7hJ/oQrM0u3xqbQdpsw2m2QWVwvn/dP4tF9hJj+nSs7fMhqdwfMBniyLHV W3vRsGqA6y8QFArAzWycIevu6uD4++Bta1WZJROVcNKHggHYbkozrtomvZqebp7VYn1B TDG9t3fwPXwBS3EiZQSiDDFYyQzzTo292Lsv33Q+Kt37bZ+MOArJcMkTkUtDgLXfu/To VOWbEeYVpuuArmO2d+lpD7m12fcv/36SEbkLNskbDsVDmuYI3F/PXNaDLl7KkNQCRWPb t3XeANUrCpYSV4W0hYLxhc3tRnnMuGvzmuUyTV1znEiV+3avQEfsS7/MxoF71SrZUICa WLZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769758234; x=1770363034; h=in-reply-to:content-transfer-encoding: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=vXE39MMsimPhoKoNy3Yqix7G7FwLtMlrZ2auUPwP+5M=; b=ALRKl1nvZa7RSPYO7iTs174vVLadEJH+tAuJxpt1u5LQx8tZch44utO6T+h3IFXrhC 8AnAE7EmrwknPMC5fY6veGxEmKOPSL4UybjhomP31gT4oOhhbucPuWO3w///9tTuSCf0 YNpfXBroTltWuqlVcUxXGOQ030G2sWNvIBcow+EoLEjBGwV8ykQHft6Z6dDjc93nTIKN zGYJSlCPS6NQuf+bIbWHpW58HjzKM94yT8PYm8v8xchF+nAj+/Vcb+MzN4tXp1DT+RJa bB/9zRnSiJRLW/6EA/zuAzuuwjWBXocUQYEGP0ZlB6KRRS1bv+hYnTumOg1kC19AERfN WTOQ== X-Forwarded-Encrypted: i=1; AJvYcCXVf3CA88sTpi2n37xwzhLZXaIbFy6WfLmxDEOf8hP7ESlloWVvSvfWQR+yekmgRVT7T73kbnjhngVjToE=@vger.kernel.org X-Gm-Message-State: AOJu0YxQc8SAecx/QW962vAMQR2Q/cVOaWFDFYqI1JYfLITy3DEXizhX FpRcClNvLulXKv8F6FJo060g0TR9gJD6URRYYw4L7Jtd7BmP+wSfMpuW9D4g9N7M8JfZY31DJ95 wrptT2cLuV+zyXJinpWluqiIaC66RIhD1iwvSHgB3Iw0XQFOrFhgan9OsY7XYvzSAUw== X-Gm-Gg: AZuq6aJr+KjRhV1plBVXNTyCjmqASymoickuogVfT3aNMFQ7s7LwclQQZVjPbK9MGZL M2ReU+FtQdXMilEc06zMEjVgHhkxYCHm4lOgBgMTt9qUVjfb6INoWar4RAxPSP3i2rVVrpkwrDF ztKwXr/LBljMtz0Ai1TBJuCjBrZvzdsewQu+4gQ+/JMZWIBrzVgWfY3Y0AIaPrBDXWJvSJeKOWx dogyo/14rmuaVWqk8hUQAoMNsNUnedW7YFBfJp3UYe/779jPC5McCxAroIQ+mlSjfOQoCgDXO9+ qa1CyAZI9Av8SyiSHWKGHsjVpViqLCGAvAzdPW3W4z94JUR7HVO+d2e1EeCy5okY+sAi3PCktKT rHx5pVuM18iSMWUMl4wRE7VPWbWg0clWH2xhv0/vl X-Received: by 2002:a05:6000:4282:b0:435:af89:11be with SMTP id ffacd0b85a97d-435f3a8b257mr2841873f8f.15.1769758234328; Thu, 29 Jan 2026 23:30:34 -0800 (PST) X-Received: by 2002:a05:6000:4282:b0:435:af89:11be with SMTP id ffacd0b85a97d-435f3a8b257mr2841816f8f.15.1769758233752; Thu, 29 Jan 2026 23:30:33 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.129.40]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10e4757sm20689166f8f.5.2026.01.29.23.30.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jan 2026 23:30:33 -0800 (PST) Date: Fri, 30 Jan 2026 08:30:31 +0100 From: Juri Lelli To: Andrea Righi Cc: gmonaco@redhat.com, Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Tejun Heo , Joel Fernandes , David Vernet , Changwoo Min , Daniel Hodges , sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] sched/deadline: Reset dl_server execution state on stop Message-ID: References: <9b8c90b1-9247-4159-9bf6-72bd71bb74a2@redhat.com> <45e4dc7a-f261-46ec-8973-0fb8d1f7b0b9@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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hello, On 29/01/26 18:32, Andrea Righi wrote: > Hi Gabriele, > > On Thu, Jan 29, 2026 at 12:48:35PM +0100, gmonaco@redhat.com wrote: > > On Wed, 2026-01-28 at 14:41 +0100, Andrea Righi wrote: > > > Just to make sure we're testing the same thing, I'm currently using > > > https://git.kernel.org/pub/scm/linux/kernel/git/arighi/linux.git, > > > branch > > > scx-dl-server. > > > > > > I'm running this test inside virtme-ng: > > >   $ vng -vb --config tools/testing/selftests/sched_ext/config > > >   $ vng -v -- tools/testing/selftests/sched_ext/runner -t rt_stall > > > > Well, that's a fun one, I could reproduce the same failure you > > described in vng on another x86 box. > > > > The arm box (bare metal) I used initially still passes just fine all 4 > > iterations of the test. > > > > > > On the x86 box (vng) I tried different orders of iterations (where the > > original is fair-ext-fair-ext) with and without the ext server active. > > > > No ext-server: the ext iteration fails and breaks also fair (unlike the > > arm64 box where the fair was intact) > > ext-server active: a sequence fair-ext breaks both (like you observe). > > > > I don't have time to look further into this right now, but it looks > > like an interesting pattern. > > Thanks for checking and reproducing it. > > Considering that these issues around DL server stop/start transitions can > be triggered introducing an additional DL server (EXT) makes me wonder > whether this could become even more problematic as we add more DL servers > (hierarchical DL servers?). > > Considering that unconditionally clearing dl_defer_running in > dl_server_stop() seems to re-establish a clear state-machine workflow, > I think we should go with that fix for now, so we can unblock the EXT DL > server patch set. With that change in place, all the server combinations > and sequences I've tested seem to behave consistently. > > We can always revisit preserving the short-sleep optimization later if we > find a way to do it with stronger guarantees (and I'll keep investigating > on this), but for now the unconditional reset seems like the most robust > fix to me. > > Opinions? Peter / Juri? Hummm, I now however fear that always cleaning on stop would reintroduce the issue John Stultz reported a while ago where boosted tasks would need to wait for an entire new period after sleeping briefly. Would it? Would an hybrid approach be feasible? Can we do "the right thing" (what Gabriele suggests?) during normal operation and cleanup state only on server unload/load? Thanks, Juri