From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f41.google.com (mail-dl1-f41.google.com [74.125.82.41]) (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 AF5663C873A for ; Mon, 30 Mar 2026 11:45:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774871147; cv=none; b=NsRix90Cc8Z6mZ/5jK7hVtkfmLWGDkmdrw6YBTPfFh07oXB+hOQP0wHPPjkPOHLmjBb5E5M+8bBpx3BCxOQaTCuw1ctFwu7KjdBVvQAO2GvqFefbRgig1VMcoDM10Wv7S3OUIfoFSSHzcWf4v5EDGdub2R7q23scIVBQbaBDZHQ= 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.41 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-f41.google.com with SMTP id a92af1059eb24-126ea4b77adso5961309c88.1 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=bPJ8GA9cAMtqHULdFSUC1AS0T5VNNeaFpTw5FN+D6bvBVPUn0CbRBuSlZZB36+CzSX gBOwuGimqyCCDwxSCYLmI4VPwYdbtpi5o4k1Vj1SogmXpXHN0IIuuVfvgPE9h1R1ZMGp bUQIKkn9cF7r0QnyFWYJoJjQ32vvgVf78jNoGdvnDHDo378oUSACbhxAIQ8l4nQrekqd 8sjKGOLLKDRz6KvhGB3tX47jd+1kuLaXC1xzNC0sb8Gduyel6tQ3JY6AUkEx87Ayti6+ DFaErCNeDojqzkyvXhwkvCLAPxb5t73YBrl7Z32G9IuGXMHbZs0S7S/UaQad8gnkCDLH 6Phw== X-Forwarded-Encrypted: i=1; AJvYcCXmVuT9tKoQlAokf/ii0LfR1S/vXdrvG6G2Ha8MX59psQ5TmSd0HzUInUUKkNnGhBwuQrk=@vger.kernel.org X-Gm-Message-State: AOJu0Yzs6cfWYRUUQWUGSyQTwUSZCvDgG5fxyxYSyiNtbZEbk1V56SoV U7yhhUVZPJDu3sFfvXDoKY1zO5BFQ+9qiNIY8S9hqKzSDZFNmetIokFc X-Gm-Gg: ATEYQzy7ghhFG2/0+1JeUYli4Wm0bSIpfXW90I6OoPWiVYNOderbsrUujtsSMduSymJ VIgGxt3KL9+OG988vhJ9oQQHIhZ4ORJtKmFcppkFMK6h5rMzg1qSFxA+9SwlXT/M1+zH8bTLuu7 oBEDAUYpDelqOJTAq3hbJnozalUHfRinaY/wLODPKmhVNibzZUmru0I0VmxNFbJOk5SOhS441aw BpmGpuJnximynLZAgEHZnW5/VgVScRgoeqy5G3enwzJUiqUPO6Kzy9x6Mdo3YyJmtaFzIAdbzxR sfqY/qjzjKRscWoX6ASJbQAX/B1eyh9W6cl0Ml7p09itHz5YampbDqxEG0dCrw8Ms1V8hbG5ha+ Ju+ITlpPJsnIezgDZSsim22uCzXpDHkpAbU63rJEdJE6ibT9PlvOswlURpq1tOmpur3SeIG/E3m hF2aOGUXDLnzZh/PLRRNkyGOC95sPom5KY+fM= 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: rcu@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.