From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794407052; b=jwwFVKPCYbdUQfn/D+iz4U5sixDUUwICbNBvWx+Ss7LP5Ey5g1uChaPVpL+MnbSR5AOA rzfqA83lKjqZYdqlf4OjQQG8YzeWdCyt7N1fom72GjiEA51Zd5+lZ/0XMviql1reJEAyp aixvtK7hOi8wyWEqAuMqSUMkIHYDz9hMAEk4LynkTsvjuhTOnilucdz82e/MtENs7nZdr xn4amvn4RIIAYiTM4E200bpMuK5y+EVi/ypfG3W2fGvIQy5H7t+jeqrLQf56B9LXGKHX3 QJN+tjTWyIiw0lI1+2vHjXcMa/28Ilcynvyq1x9nAN1aO2Cn1etWX+tNTSQiUDhaBOQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794407052; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received: X-Received:Received:Date:From:To:Cc:Subject:Message-ID:References: MIME-Version:Content-Type:Content-Disposition:In-Reply-To; bh=Npgvb84M0kJgdnmAsSFiguDvaupmEXtt/RUSJRF0Wy0=; b=OqBNnJRRwsZoO9qVvIcoQ3+XYf7qhimRLFPyDssING9+rxiCmAqM5hlOzhT+2NKhJ3Hs nVTgPJe1wJ7/HC6O75EJyTRXyt4LAeP7erGReCIjVIZ09RMLA/biBGZPFs1QpDbuewAWE CsZAQshuTFOImdb7Ial/fVtRiM1YBwLUccKLYPvRdGRemgw2jN9NiTGmReeg6CssLRuAT 3FKdlmDOfZZPpiY7kcFCYMh7LMyslvwrRHFI6C/ew6F3d2NjWF4Tuz6C4wRm7lv0dz6VJ xFjs6UOO1yDzX47trfQpvM9kXlK2pS9PvgueAl5+eyRvP18qBeEeRDPJSph5mXi8/uw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=eVzWKmBG; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=FarBWl8t; arc=none smtp.remote-ip=170.10.129.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EE939606A337 for ; Wed, 11 Nov 2026 14:24:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org EE939606A337 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.a=rsa-sha256 header.s=mimecast20190719 header.b=eVzWKmBG; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=google header.b=FarBWl8t DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1794407051; 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=Npgvb84M0kJgdnmAsSFiguDvaupmEXtt/RUSJRF0Wy0=; b=eVzWKmBGewX8fRDmN1htbG78LXSREfinw3WIfGRjv9KpxYzn9SOnbV+yz4gSfGotV/l3k5 8J58EGnplioh0JYSDxUb6YtocE+xJjj4SQjTcZ71DiFTHzsX/fLIlfw/vDk7Dfz01IMaxQ q7s559663/DJ8L1aPfsAQZcvLrjrsh0= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-671-omeZ030OOfK65uartQ4F8w-1; Wed, 11 Nov 2026 09:24:09 -0500 X-MC-Unique: omeZ030OOfK65uartQ4F8w-1 X-Mimecast-MFC-AGG-ID: omeZ030OOfK65uartQ4F8w_1794407048 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4a009f82bedso24991245e9.0 for ; Wed, 11 Nov 2026 06:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1794407048; x=1795011848; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Npgvb84M0kJgdnmAsSFiguDvaupmEXtt/RUSJRF0Wy0=; b=FarBWl8tvXi1UumnOLvjKyNUvGVvqKHBHvz0IwXEUMy0YT8wcU2U17ezae3ntnt0H4 NiODWSEc9if6AOUfpL35fVd4CzqFkaozQ6YVSAENATtvpcLg3i67R53enj5BOlj1mpH4 SE8hiV47ncV0WTfVymNUbic40PN9LqQtxQDDvq6nANt6LVGwNAkwFSkOuQir4G+Zd+6g QY3q3q3sKHA8SNJPgHv2Xlh0/TO+hRNmN1mzrZvcu/7GYGpViozASL5Mjisa7zEGif/W Xxl0TdYB+vfxfpvpI2la/V3DB9P8oPxsZpiVnR8G/Jo998aGOc8elIXyRsLYdwTS7+85 ig/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794407048; x=1795011848; h=in-reply-to:content-disposition:content-type: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 :content-type; bh=Npgvb84M0kJgdnmAsSFiguDvaupmEXtt/RUSJRF0Wy0=; b=pFRywtnGDrdLnfM0jJD85WQGehv376mrXfjdRSDhtOw/bnPbXadpKi6jb/D+/VvlYx kGBivYMChnVNYpACuUf5JK+7ZtVI7kM0obHXMw/V3aGsWdZB7oNcgKUEVHjfvTQTgpSR FItVRFt813XNI0SkNiu6OWFmdekOizn45mT8tpGeeSyBR80R3q/yQ9a6PHbhdOXEojOL a+8Vgx1jr0SQFcK9VIgAXT9UqzBj3Vbw2BMn5VInH1iouPWBwhH3ZsGujTzgkrmm5LhZ iShJSnQ29zhJLidM5vRpSF/1xkSc1uHj0oURPgqj8cH28q/8RT9KgYg17FPWohp1Iti6 QtZg== X-Forwarded-Encrypted: i=1; AL+hErEKiOonoNj3d+mKAEYZNEwB/+ZSDQRxoo164kjpFRUDLP978PleZzmpIYUnRQeSr+oWPi6aG2bCordsoso=@vger.kernel.org X-Gm-Message-State: APuU4Z/jQSDGRlCW4UsAgxk6tagN6I5bQxdh4WfvNvxoHAwbuYNqge8J hhNpv04nLHICPlDPFxKl2ZoovZRP5I/YDhCluwG+2p98ARWV4nHO3UGAb6grLUQH6Fj0XXbc8/1 S8ljrau7fVGz7kZ7vrHmG3qPFEKUJg7Vlj/7bO4C0E4ugcB8ALfOCBiBM4HB1vXtwpA== X-Gm-Gg: AYBFou3Hcrr5GsQ7qCKROEukzS28eBLGW8CHV3QWzcvKT6UQLgUxIdRwfY+HzR5XKhU VZN+Z8KMyVPA3+o9ZZPwI+Sg18w1AHvuEfUPn9qBZbV+jScwlRFY2CXTQN9NYVr8jI748gxjfW+ ofqL4a1L1KkXoyXH7610YCLxwpOOEw47xoAt1ehsXnBbUWSELWVPZA2UJlsFRpa4irGYz0MigL5 H4Uy7+lI+BxSutlugTmyPqxajlx3eElaoDwf+2/xcRA5QE+B/pMSwwil9aCcn0UiBgV+bbIVPha +bjhJhdFFzHSBMgHBPx8d5BBsMlCiy+Cq58sNeAqvFHyGI3qRplVhEgxoelZ4Wfsyaf3jBA7tvD UGAhWoI8C5ZIrxgDulIbY0bfJQL9TQ8evWoCpqOwNM3mujcKnisCcdS8EDh+6th3D5kM47AT65K stAck= X-Received: by 2002:a05:600c:840c:b0:4af:c210:5b3f with SMTP id 5b1f17b1804b1-4ba09377dbfmr46939585e9.24.1794407048205; Wed, 11 Nov 2026 06:24:08 -0800 (PST) X-Received: by 2002:a05:600c:840c:b0:4af:c210:5b3f with SMTP id 5b1f17b1804b1-4ba09377dbfmr46938695e9.24.1794407047403; Wed, 11 Nov 2026 06:24:07 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.158.90]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4983585c5c4sm9579508f8f.17.2026.11.11.06.24.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Nov 2026 06:24:06 -0800 (PST) Date: Wed, 11 Nov 2026 15:24:03 +0100 From: Juri Lelli To: Mathieu Desnoyers Cc: peterz@infradead.org, mingo@redhat.com, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org, tglx@kernel.org, will@kernel.org, boqun@kernel.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, luca.abeni@santannapisa.it, mathieu.poirier@linaro.org, longman@redhat.com, ridong.chen@linux.dev, tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com, shuah@kernel.org, bigeasy@linutronix.de, clrkwllms@kernel.org, parri.andrea@gmail.com, m.szyprowski@samsung.com, kayracizmeci@gmail.com, weihengqiuu@gmail.com, cgroups@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-rt-devel@lists.linux.dev, stable@vger.kernel.org, Qais Yousef Subject: Re: [PATCH v5 15/29] sched/deadline: Rebuild the root domains' accounting from the task list Message-ID: References: <20261108185406.1549770-1-mathieu.desnoyers@efficios.com> <20261108185406.1549770-16-mathieu.desnoyers@efficios.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261108185406.1549770-16-mathieu.desnoyers@efficios.com> Hello, On 08/11/26 13:53, Mathieu Desnoyers wrote: > A rebuild of the root domains, as on CPU hotplug, clears their deadline > accounting. dl_rebuild_rd_accounting() then adds back the deadline tasks > of each cpuset. Without CONFIG_CPUSETS, it is a stub. So the first > hotplug drops every deadline task's bandwidth, and their releases wrap > total_bw around. In testing, a root domain admitted 9 tasks of 10ms > every 100ms before a hotplug with deadline sleepers, and none after. > > With cpusets, the rebuild skips a cpuset whose nr_deadline_tasks is 0. > This count spares suspend and resume a costly walk of all tasks. An > attach moves it by a tally taken in cpuset_can_attach(). A task that > leaves the class between the tally and the move is taken off the old > cpuset twice. Its count can then reach 0 with a deadline task in it. > Every rebuild would then drop that task's bandwidth. > > Fix both by walking the task list, with or without cpusets. The walk > finds every deadline task, so the count and its hooks go. It holds > tasklist_lock for reading, so fork and exit wait meanwhile. It locks > only deadline tasks, where the walk that the count avoided took the > pi_lock of every task. It leaves out an exited task with a dl_bw of 0. > It also leaves out a zombie whose bandwidth an earlier rebuild dropped, > as dl_clear_root_domains() does. > > Without cpusets, a new dl_accounting_mutex keeps admissions out of a > rebuild, as cpuset_mutex does with them. > > Three hotplug cases of deadline_bw_test, added later in this series, > fail without cpusets. With this patch, its five hotplug cases pass, in 4 > VMs. Its death_zombie_hotplug case tests the zombie. The Sashiko AI > reviews of v3, and of v4 before posting, found the drift and the exited > tasks. Its review of v4 found the zombie. > > Fixes: f9a25f776d78 ("cpusets: Rebuild root domain deadline accounting information") > Cc: stable@vger.kernel.org > Signed-off-by: Mathieu Desnoyers > --- As you most probably know, the count this removes was added because Qais reported 10-20ms suspend/resume regressions from the old walk on Android, and the merged fix was validated only as "delay no longer noticeable" on zero-DL systems. Added him in Cc. The new walk drops the per-task pi_lock that dominated the old cost, so the approach might be OK, but since this is Cc: stable and will eventually reach Android, maybe someone from there can confirm before we pull the trigger? Alternatively, a single global "any deadline task exist" bail would keep suspend/resume free for the no-DL case without reintroducing any per-cpuset bookkeeping to drift? Thanks, Juri