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 BA5843043DD for ; Tue, 27 Jan 2026 16:00:38 +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=1769529640; cv=none; b=ZdnknDEaf9od/FqOzmWkZChaix2Y0JE8IKhHgjYyf4Po7k9BXlv87djcnpjnhMIJCYHHx6yQAjVwfvaBlmHNC7g5O5zzd8jI4K+FlXJQaGNUTej0FNb8Rhot2AVM1d6PSHQ2XDqkc7tKDmPEqkObVklRXzSJLy7dKUU5NxeasGw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769529640; c=relaxed/simple; bh=bCEyxMDbMXjcD5Q4ndMCEOt8U5L9TJj6jcgUsqmd2D8=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=IHSTIubdMHkDirOXNriTx8AIb9KMElpB0l5r6pxhxEYIcximhiEil5QgQiVW7UFuFAW2a+/5igVL4My8h+g3eOS8P8otXQRLep+pxBWcwvHXd6kq3yTJC5IYS/Slf02NQuGuoBTmINVhz9ulaCNpBS4BVQEbfT7dlmK+AUKv/no= 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=FIfR7VvB; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=kw2hbhf6; 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="FIfR7VvB"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="kw2hbhf6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769529637; 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=bCEyxMDbMXjcD5Q4ndMCEOt8U5L9TJj6jcgUsqmd2D8=; b=FIfR7VvBCgoCh7iVSlceDApq7JpU48a5YI9mqdYXrQ8EDaLaBzfnLx/RTTekfN/1Zn2b67 Dha0pqA5/te5DxMmGKZR0FDmZUZ1x2LenEicmgIVMf7Qztxda2grp2OAiquHxkuLhUstiD vKND8CCI32BAAzRlyM5jD8l4PuKP2sM= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-31-icmkZFRCNPyIUy82SoKFQA-1; Tue, 27 Jan 2026 11:00:36 -0500 X-MC-Unique: icmkZFRCNPyIUy82SoKFQA-1 X-Mimecast-MFC-AGG-ID: icmkZFRCNPyIUy82SoKFQA_1769529635 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-b8709d4ff20so380189266b.0 for ; Tue, 27 Jan 2026 08:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769529635; x=1770134435; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=bCEyxMDbMXjcD5Q4ndMCEOt8U5L9TJj6jcgUsqmd2D8=; b=kw2hbhf6x1n+lIsPGVi9fXJTr933db3YYUFTjY0JkbfwPm2fwr7sIZx+H4aUbatX4e AzI92qNSHTV55RiS3+hPWZ8aM3ioN6UZwhhdfjZhqR5aDZLZXgRd4xJEs1Rp89+1Qchh KfgTXgtals62wOSGTM/rbydIdVgcJ/5OzSMOAcqjNTwG5wobsNZH+74zH55UqUaey3Wx FaftnxOx2NB6FK6z/pATeHnt/mhVfv6F8Kd5zfEb+z3WXVQ5F4ABxacmIPq/agm97pQC FWTOw9+lIZ3SmDJPzz3d8jt2bCVNr9Wxnc5HMaYfgoNTI0f/KTn9LHQ+HtlErQf5iRmP Kfjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769529635; x=1770134435; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=bCEyxMDbMXjcD5Q4ndMCEOt8U5L9TJj6jcgUsqmd2D8=; b=cOZrgeuecJjBVoEzHCbITZipwE8IqYKVzxGQeCtow9ODJarua8MRno61zGaSKu+oQx KSlFJvovTDAf4UvqHyvrn8tJtNVtyLdKW0y3X84OdNQzVkX6n4qH76w51JgZe8IeJdn5 DYdvMeUDhRR/X4k/NOB8GotzP4CuUuwNEV/FNVtyWq2t9ER1ljsqZ5fqNZL0mahxIfH8 25tugAvymo0ex1+rAVHVMtGcJZR6JLSF1Gz0o82ikWkd1S73fn5pZs1CMIQGq46mKWnJ lqR0N2Bu8WAmWPOoTYRQSXgdcWORAksY2QVLzb6UcxIISLM/knoXVk/JdUInaXj2Fq9y W1nQ== X-Forwarded-Encrypted: i=1; AJvYcCW1c8MNsQN6aj7KzbMDF8TUo8aDiEAXdX2XqXYiQCrSpJj565mbJC9gmUieV6KKDhzOnHB/0+fHpInNw2s=@vger.kernel.org X-Gm-Message-State: AOJu0YwNvlqQUHKTIzmSdNAVBqsRv0ULatvJdS0zGEsjW7bAo5zXqUUW QvyKS2fVIBSXEobB4roi7MDVPyPa7PtPX7AANZTwLDqhMR9d6EtwrzJDqbRJeZUfoVcvabNdVCU B92FfpAUXvqH1rdO3snTZQjyXQ+9SaGSrx9d47CdKCBkqqvNECNrPaWMQsaaqMNTd2g== X-Gm-Gg: AZuq6aKBfKS3hHGWOUV2KAvAqYCY6TrCcJRk1c97fPovNJ/4bzP8lc3E9gltet3rBaf olJLTUpTR0ZJCvN66nsnuweX2DUCzZzMHfhD/YaX+mqEg2XtHlBVZV4MC1DiyWZjtHh/bU2Rnz4 dyZn/msKUWdiIxXEWZyeemDRx1G9szGTPq446NscY4cwwc9dxlna9aDCAx8XPRgLezKFLu+k8ap U3xJ51f0T/pySe1NW3uw8XXt0eOTwpjDiNK9ERD2oFCl1xjYAh232RlNKRuioJzuJbVRVck0BLM 8ulOw9qp2a81coHF+slwaYi2kILLz7jOF4qcANHdz0/Uwx3DOdEwFXEesX3W/WRbIE7GozQyr1A zoHZU/A== X-Received: by 2002:a17:906:c108:b0:b80:751:ee62 with SMTP id a640c23a62f3a-b8dab3048a2mr175431066b.14.1769529634930; Tue, 27 Jan 2026 08:00:34 -0800 (PST) X-Received: by 2002:a17:906:c108:b0:b80:751:ee62 with SMTP id a640c23a62f3a-b8dab3048a2mr175427966b.14.1769529634427; Tue, 27 Jan 2026 08:00:34 -0800 (PST) Received: from [127.0.0.1] ([185.168.96.228]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b885b445747sm802335766b.30.2026.01.27.08.00.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jan 2026 08:00:34 -0800 (PST) Date: Tue, 27 Jan 2026 16:00:31 +0000 From: Gabriele Monaco To: Andrea Righi Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , 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 Message-ID: In-Reply-To: References: <20260123161645.2181752-1-arighi@nvidia.com> <9b8c90b1-9247-4159-9bf6-72bd71bb74a2@redhat.com> Subject: Re: [PATCH v2] sched/deadline: Reset dl_server execution state on stop 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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: 2026-01-27T14:18:29Z Andrea Righi : > I think my case should work also doing something like this (I'll run some > tests later to double check): > > =C2=A0=C2=A0=C2=A0 if (dl_se->runtime <=3D 0) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dl_se->dl_defer_running =3D 0; > > In this way: > - short sleep + remaining runtime > 0 > =C2=A0=C2=A0 - dl_defer_running stays set > =C2=A0=C2=A0 - restart can go A->D directly > =C2=A0=C2=A0 - no extra defer / zero-laxity penalty > > - stop with exhausted (or negative) runtime > =C2=A0=C2=A0 - dl_defer_running is cleared > =C2=A0=C2=A0 - restart must re-establish eligibility > =C2=A0=C2=A0 - deferral / timer is armed again > =C2=A0=C2=A0 - no stale "already running" server Yeah that looks like the neatest to me. Fair tasks are a bit more penalised than now but won't be if they really sl= eep before consuming the runtime, which I think was the whole point of this= logic. > However, I think the right assumption should be that both runtime **and** > deadline are still coherent, so we should probably do something like this > to be fully correct: > > =C2=A0=C2=A0=C2=A0 if (dl_se->runtime <=3D 0 || > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dl_time_before(dl_se->deadline= , rq_clock(dl_se->rq))) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dl_se->dl_defer_running =3D 0; > > This makes the stop path slightly more complex, so I'm not sure whether > it's preferable to go in this direction or just unconditionally clearing > dl_defer_running, which is simpler and more explicit from a state-machine > point of view. I think it's trickier than that. The state machine is coherent as long as t= he the server is restarted after the deadline, no matter when it was stoppe= d. This check should probably be done at some point during dl_server_start(). But yeah it's probably an overkill. Thanks, Gabriele