From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f49.google.com (mail-dl1-f49.google.com [74.125.82.49]) (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 ACFF93C8728 for ; Mon, 30 Mar 2026 11:45:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774871147; cv=none; b=J4a2cQKiJ0rJk4VOvL1YRte4vUb40PYvgwPD36Wen7bvZa9G5DGJLHw2cGnAwhicd2dB35xQDCBQWQ/j3gEfU5oS7SiS7v/Eal7utdaAoNfvP+zRNK/OSoFzRGWe1TElLUXMQk4GnuERocHKKPM1Ej9o71n4MkYM+NI2xtTs8p8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774871147; c=relaxed/simple; bh=ENYJkWvXLcVtI7Jk9TnX7QADJtn30XJLoRyTZBf96yo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oCVGAFOqu80bzlO9lPns1ITXMKl2hHLlWP9XGIEpXCKHeukggrSqBko9K5UlDvuU2RLt62f6F9Z45yPv735spa2l50qw6UAuzD51lAApyzPB00fN+FaQQzIfLXDSkWICHjss+UWU3b4oQuL5CbnqnJi+zL3lAwwuD2bmnyLrT7Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=csz2Yapg; arc=none smtp.client-ip=74.125.82.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="csz2Yapg" Received: by mail-dl1-f49.google.com with SMTP id a92af1059eb24-12a747e7b2fso2019279c88.0 for ; Mon, 30 Mar 2026 04:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774871145; x=1775475945; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MnDbxuScG9Rm/YGh2qPYK61S3SeIJ/p/OHYJTOIzac4=; b=csz2YapgXBdCd1QSpBVbPiyh1Z8pcOHOAezCYSwazGTtMUNhPAGpgezRcwV7WrUbAk 1ffqvlWFZ9Le3E126zVCMIkrzIRaKbvN1S/8NLyts1QlQIbp0DSPR10SnirxQ5plA7Q3 XOHSwleO+0y36mQf6b8XOvdM5Sl4EdMvWGfkilgZAADybQXBBgaUTLwyjWk+842K1eGE 1Pw6ygco4yfpDBCuU4DU7/xUZFzrGeu2k+KWJ+IiHABHtpVxEyAIcsCExnQrfr79cXXD 77H/3UumUSmRB3z3QxWbJ9oeCdr+FCWeVIp8dg1Bi8zl/Mb5ZcwqVPE6qebiX0m7qcOE UYvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774871145; x=1775475945; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MnDbxuScG9Rm/YGh2qPYK61S3SeIJ/p/OHYJTOIzac4=; b=Uv90zF2Kh+Wt97Hc3EonLLE+eZPrZpXCboqvfm56PDuXJ9k7EsnYZ6x9nfjmE1lcEP MdMNyDMarb700nWiBfdyk+cDWA2qzgTnrvdMi1oj5RGPDy2L2VgshWS8PnvQcLfD4wue Hllx+zXwRZwWJ8OJk7em+g4tLc0/ISV5Q3SASoSE0+MIdvdavFPBGGCTyiO+Ny5dO0sh UPmHVvgkrxPlwlOfQnt+5AWTULzANqYXn2/mb8cNiTYD36hSwCSHeBqcKomeKZ8Bz5Fd rr5iBGZX2OA6mrRMb0y5mWDe40l44NQNrpBEXRbghtdvckeH4w/RaJkZrb+aUu7ztXOU OpMg== X-Forwarded-Encrypted: i=1; AJvYcCWkNaL2CjiDaeVfskqkEOZvfPHl0i1p/G82ju3y8cXnVeRuBqy4hOUDvHKxWpbjbNs10GraSdY2Mi7+uwbkgfM=@vger.kernel.org X-Gm-Message-State: AOJu0YySWxjCOtUPT3/lDaibqoIhAcZDkFHYRmtMQo4UXFjfjKG1MiRm sS2Al3o0qJqz0rigQ/8xV+SQ+Iklk/LHuQzvw7vaeYTT2F1hfQA0KCRX X-Gm-Gg: ATEYQzwboNlPtUr8KCtQR2V8+3zmaDpjHlE0a1Mee7p0zY6b4dfiWjcb4uvgd/+0vhs RJkPDYWpf+U9B4w4t/LoGufK4WZyL71gihi8XbWbqqnE64KqHO93noKMiB6i1HM8dOw+R4El6UB xrJTY39ImnscwvwbUJiAa8UrEro0RXvbqOK2V/QVbRnTma/ukW6cdDfXlkHh+hNsYHTOiwS/O+9 iDY4ppkDewnaaOKT6g/iyaeJoO8pl+sREifUx4YsjyWZKCRo/Kx0NN0xu+oi0Htmtd6EMmE9cLL 3sI5JhuXGW+uBU2/ITsRa//75FEcCvYfr1eMB4qN20Aq4Jo58CQcDUoxTn74eCPjuewG1yEK4uH R6G2KTqSsNWQz/rA7m2HCwIfa06+Yd5T/U88uoZO45DW1kUhDpPpJKG2m2VXZfvy3uHNZ9GN2w+ HrTu1cvY1hzenBRWJZZ2zJdQrz+864JZSMXac= X-Received: by 2002:a05:7022:b91:b0:128:e0dc:6428 with SMTP id a92af1059eb24-12ab2897c4emr6271373c88.17.1774871144768; Mon, 30 Mar 2026 04:45:44 -0700 (PDT) Received: from localhost.localdomain ([74.48.213.230]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-12ab97e7a57sm9176288c88.6.2026.03.30.04.45.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Mar 2026 04:45:44 -0700 (PDT) From: Qiliang Yuan To: peterz@infradead.org Cc: longman@redhat.com, cgroups@vger.kernel.org, akpm@linux-foundation.org, anna-maria@linutronix.de, boqun.feng@gmail.com, bsegall@google.com, dietmar.eggemann@arm.com, frederic@kernel.org, hannes@cmpxchg.org, jackmanb@google.com, jiangshanlai@gmail.com, joelagnelf@nvidia.com, josh@joshtriplett.org, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, mathieu.desnoyers@efficios.com, mgorman@suse.de, mhocko@suse.com, mingo@kernel.org, mingo@redhat.com, neeraj.upadhyay@kernel.org, paulmck@kernel.org, qiang.zhang@linux.dev, rcu@vger.kernel.org, realwujing@gmail.com, rostedt@goodmis.org, shuah@kernel.org, surenb@google.com, tglx@kernel.org, tj@kernel.org, urezki@gmail.com, vbabka@suse.cz, vincent.guittot@linaro.org, vschneid@redhat.com, ziy@nvidia.com Subject: Re: [PATCH 06/15] sched/core: Dynamically update scheduler domain housekeeping mask Date: Mon, 30 Mar 2026 19:45:16 +0800 Message-ID: <20260330114516.103451-1-realwujing@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260325140053.GC3738786@noisy.programming.kicks-ass.net> References: <20260325140053.GC3738786@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kselftest@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, Mar 25, 2026 at 03:00:53PM +0100, Peter Zijlstra wrote: > Sched domain boundaries are not static, they are easily changed by > cpuset partition (v1 and v2 both support this). You're absolutely right. My description was imprecise. The goal of this patch was to ensure that the housekeeping mask for scheduler domains follows the partition boundaries dynamically as they are resized. In V13, I will explicitly integrate the housekeeping update logic directly with `cpuset.cpus.partition` transitions. This way, any change to the isolation level of a partition will automatically update the kernel-internal housekeeping state, avoiding any parallel management logic.