From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793718842; b=VAeIyY5AOuCMx7/DIitZbEgAtK3/ruiJh2g+B/q3EDFkSYoHRdholmz47nW0xHQNTIsV NyaIN2nUFojOkbj6YyFnIhs0outNrc5irNuML5Rst3hNlgdLOX16zKV7Fphtx6LLKDcx7 5rFZ63Q5FaFae4fDGwhqDDA+d5H5cudM8Q3O2YSasrjxb7WeKAnBJZkbKmo28aWNieAw5 bqzT82E3UaIW8g4yVF8va0tgm5g6ocDu39WJZztu6IHWCb7YGn5j0qWArpxwZ6ps36MJE HNl8QD4BHnPSv193kXGGBxATR+CuzSiyiI2cn22Xaf+5c513u4m9xui7ccgLrjGMrwA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793718842; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:Received:Message-ID:Date:MIME-Version: User-Agent:Subject:To:Cc:References:Content-Language:From:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-Scanned-By; bh=In5hDuKiBdou1zv+joOPBenp7vdBADvUYuAlqVBsoTA=; b=xWirBy9jFSMuQ1bIkpqrfaF8oYrTodZ0THUOsSLuF8soVg8g/s9qED5zH6Jydqzm5aRA D4BKqe2SrLPnPVgyPkjhkx1GPTEYVb0DZ1POxQSCOvfJfIAJi/3gHukA7WSsuS7/9cw81 cQyWUNwnHrjPwglFPCzOYEMGuzN4hXE2fw8ReVcEmph0DsB3W2zOgejCAYSwkyqEn0dND hRpsQ/3D02VRiShxlG7WQ92FlMFiF0Z2VQt982KUT8L545pxmoZUE4jyl1+OwmjiCCQzV ShTSsq7rGlgpUooun8bwxz5AYSSoltNbDkvoEslTSUpZLHhfCRe7e+RueAvikuhmyqw== 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=Ll4zK9kp; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.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 9A617606A33D for ; Tue, 3 Nov 2026 15:14:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 9A617606A33D 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, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Ll4zK9kp DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793718840; 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=In5hDuKiBdou1zv+joOPBenp7vdBADvUYuAlqVBsoTA=; b=Ll4zK9kp0vs716v31WEvpc3/0vtAp9wiRoNYOzGxbjhN2W1txgHvwM7cs9REy6u3nt+tvY r2SiHTpDa3DLwXC5Y1WZSJJ06PFHDrGgosdG1+eBSM4OrMioT+VTsQqYP9hLHWUhn9jCsb eI2yvWyOK1rc/GtU7FryeoCkut4mBu8= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-496-8_7V8QBKPBibu_MNcB0H3Q-1; Tue, 03 Nov 2026 10:13:56 -0500 X-MC-Unique: 8_7V8QBKPBibu_MNcB0H3Q-1 X-Mimecast-MFC-AGG-ID: 8_7V8QBKPBibu_MNcB0H3Q_1793718826 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 37FD5180065E; Tue, 3 Nov 2026 15:13:45 +0000 (UTC) Received: from [100.91.18.181] (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id BF564195608C; Tue, 3 Nov 2026 15:13:39 +0000 (UTC) Message-ID: Date: Tue, 3 Nov 2026 10:13:38 -0500 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 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] kthread: Keep unbound kthreads off nohz_full CPUs To: Frederic Weisbecker , Matthew Ruffell Cc: Tejun Heo , Peter Zijlstra , Ingo Molnar , Andrew Morton , David Hildenbrand , Caron Wills , Ridong Chen , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , K Prateek Nayak , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, Jay Vosburgh References: <20261103075940.110308-1-matthew.ruffell@canonical.com> <20261103075940.110308-3-matthew.ruffell@canonical.com> Content-Language: en-US From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 On 11/3/26 9:01 AM, Frederic Weisbecker wrote: > Le Tue, Nov 03, 2026 at 08:59:36PM +1300, Matthew Ruffell a écrit : >> From: Caron Wills >> >> Since commit 041ee6f3727a ("kthread: Rely on HK_TYPE_DOMAIN for >> preferred affinity management") kthread_fetch_affinity() only removes >> domain isolated CPUs from a kthread's affinity, assuming that nohz_full >> CPUs are always domain isolated as well. Up to v6.13 every kthread >> inherited kthreadd's affinity to housekeeping_cpumask(HK_TYPE_KTHREAD), >> and from v6.14 the preferred affinity was filtered with HK_TYPE_KTHREAD, >> so nohz_full CPUs were always excluded. > This was done on purpose because on all setup we have met so far, it didn't > make sense to run nohz_full with load balancing. After all the point is to > run a pinned single task on a single CPU. We have seen too many misconfigured > CPU isolation workloads due to that constraint not being enforced since the > origins. > > I'm open to counter-arguments of course but you better have a good case. I do see configurations where nohz_full/managed_irq CPUs are set at boot time without isolcpus=domain. But these nohz_full CPUs are there as a backup in case some latency critical workloads need a set of fully isolated CPUs to run on. Right now, isolcpus=domain can be set dynamically by using the cpuset isolated partition feature and they will be used when the need arises. Matthew, is it possible for users to adapt their workloads to dynamically domain-isolated the CPUs before running RT tasks on them? Cheers, Longman