From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34AFACCD1A1 for ; Wed, 18 Sep 2024 11:17:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BFE836B0085; Wed, 18 Sep 2024 07:17:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B863E6B0088; Wed, 18 Sep 2024 07:17:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FFB86B0089; Wed, 18 Sep 2024 07:17:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 81EBA6B0085 for ; Wed, 18 Sep 2024 07:17:15 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EF757804A2 for ; Wed, 18 Sep 2024 11:17:14 +0000 (UTC) X-FDA: 82577607588.26.B1D024A Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf28.hostedemail.com (Postfix) with ESMTP id E5806C0008 for ; Wed, 18 Sep 2024 11:17:12 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bXpxa85I; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726658201; a=rsa-sha256; cv=none; b=RkOrwCTDKZ69A3v1A+b15tTwbse12lYBUf5KfwKz58kYtfnZIXS+VaXhqYTgi/kRlklxmw U6zeBzNcm4aL7Z2uiOI7yR+LxdFOdURHMeoEwIlVNDGtxnFGhRmdwEcL9RF9WQJxY6CnwQ iSXcp1WTFCUIyc7evrlc4AOTE4wZ5cU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bXpxa85I; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.49 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726658201; h=from:from:sender: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:dkim-signature; bh=deGMdGgLkdafLLe6g3k5x1mHPfDLyArAU1Qq7LyVhxE=; b=g8j9gksmPwNeNOM6VT9KVZt2uoFfRdVNmC+DS2DK3hoU3ruKFL10n5ZYesjZa1zD3JCbCX wiYyjbVCIAa2GydWCYuPpYEzF1EqueNYFqO4ovDzXZp3cASe6PRT5EcZbjj8TRnfR6fsXo zSIDkC9roh4vhiPRpL0hS1Jk2kyXw4Q= Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-a8a7596b7dfso115943266b.0 for ; Wed, 18 Sep 2024 04:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1726658231; x=1727263031; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=deGMdGgLkdafLLe6g3k5x1mHPfDLyArAU1Qq7LyVhxE=; b=bXpxa85IVTRJcvV4Zth9IXK8rVYZBCkGgGeNWMx6EG2+yvD4p1gR3Ut/3FF5Vo4uQv iTPQGxxiHUbV5MVJbauBAsRPZhu3Lnr65QpColXHH82GFDbDIOsOm6B4GyikSvpPiz/s 9JuFIrLK7O77JlUA0VpBry3/fU9tgvyP4WECdrCTPlBUVxtd+KouByk7MJQkZQdXojrr 4TWGoT9Z4fAxI06SXGWLFkMFdd8H4Oiw1euuaq3zqPFqXrjF9GoYeMgpb5wjRW7/1Nrz He0H2AXFkxk0/3v4ioHC6z2sWR2mguPVeDMcGTwoat7dFUpQ85DiY8h6Cd9SGb89knMX EyaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726658231; x=1727263031; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=deGMdGgLkdafLLe6g3k5x1mHPfDLyArAU1Qq7LyVhxE=; b=enQN8HywpGikXAzsKmbnAlBCskWKD2Xf0H9EnmKC1jB9JMNi2xB8hoOhRNekuu0kV4 84TVnrI43OazNsPCk3esA20ThzVXlx6Q2NSTegxbbr2Zygd/4DNCjHTX8q4gioZuAoL4 74J2QIIDu32oq+q9zaobfdDyxW2VB8Af8kY3102FbppLddxo3hIbdwxjR7tXWn24zoLp RXgs3k1fduUKCeuUXqgtaLPhjuy4XfQh7uhxFX9hgK+SmjBkrRqOjk8h2gFwVBzMyCoU 2v1SMD4BEzeXVoPXgy6Kov5GIAWHXLGq5UMfOyvSUdOfWUhQM/K8lVQHPCBDBVRL3fPa YAYQ== X-Forwarded-Encrypted: i=1; AJvYcCWU7WiPQ6dnmEPw79anB4XTpuRAHjGlA21+xJr7Cl16KRSO2Zxz1PPu5VG2uBg/993fcxYOqX+Q9g==@kvack.org X-Gm-Message-State: AOJu0Yw4y9PZiVb3dk0IdMQOKYsFMYkk6ePhbidQmRotgVGNxMwsnvPv qIhi31YO/xhTx1HUhy6TkKQawV/22YHmBYRPd229CIDpItdoVTtMgXg8r2Hn9n0= X-Google-Smtp-Source: AGHT+IEqcT0O/K1e5DJ3jUxfCJKVJ2bCW8ynrWruUc6SYiGDqjCWkd9rDT9dHvznNcVFqSO2GhqOhQ== X-Received: by 2002:a17:907:60cb:b0:a8d:59d7:f92b with SMTP id a640c23a62f3a-a8ffae3a32dmr2741940066b.30.1726658231269; Wed, 18 Sep 2024 04:17:11 -0700 (PDT) Received: from localhost (109-81-94-244.rct.o2.cz. [109.81.94.244]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9061096694sm582699166b.19.2024.09.18.04.17.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Sep 2024 04:17:10 -0700 (PDT) Date: Wed, 18 Sep 2024 13:17:09 +0200 From: Michal Hocko To: Frederic Weisbecker Cc: LKML , Andrew Morton , Kees Cook , Peter Zijlstra , Thomas Gleixner , Vlastimil Babka , linux-mm@kvack.org, "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Boqun Feng , Zqiang , rcu@vger.kernel.org Subject: Re: [PATCH 12/19] kthread: Default affine kthread to its preferred NUMA node Message-ID: References: <20240916224925.20540-1-frederic@kernel.org> <20240916224925.20540-13-frederic@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: E5806C0008 X-Rspamd-Server: rspam01 X-Stat-Signature: nb1k18phbkwkrf5a1ay1hdw77to6qpci X-HE-Tag: 1726658232-38654 X-HE-Meta: U2FsdGVkX1+owtoxXM/M/d6hwLeY7UTIJLd7LI63tublha6UvRh11VIjFAdO8TrXBpidBsLLweOuGonSaluyudxc0sLGYbGjUbvVw6O+mwJ2hf+codiup5EiolbqnJvpvZy9e9yvx4K0s8iQ8zBLtL+gic7aT+sPfRhC4C6LfJOLUsSUfqG6U6u08DsWiX5gNIOIbpPUeadjb2stxGk9WO3Eyan9BfyyPT5xf4+UErffMfK8eaVzVuIIVFwq+X6DU7JE0WlaDbcZxLgY2zc4quQSJuyVf44qKX3J9AeyQ8nIB8B+wUCy62bAS5A80NOyypmIF/MCJiiy53ZVwa5aJSCE39YCyRgd+DVlhY5ShdGQKtL5l6RG/01kC83gJZe+Er8ZE9Ybn9j4K/rUhqlYOxGHCFcUEye7BU+FyDpHNZNH0N4yS5e+TWkyMcxisyPvaCC0/DmY0FXG1MvaUjCub0uI8UCBtE0zDhx7/byEiVcZ+hDY/oIUEBIl/O9Ns+GAAw2bgQveR42Lc/phxJdUNBEjYm/I1o6cEBqZXfYKod7o2hgENs8noNcjXTUVkYJNbneyP4Y+vaGfpS7HTlQ798mYbb/crpXC5KovGlcgUkGjygRbZyOdDLjnunfhNy3rwSHU0ZshtsitJBJPecmgDd2h4NrKD/P+UEsTeKdK+y7699Bu+inLOaNz3qApx5VjQzkoQnibs1+a8vgVu2dsxtzm69pVycZ0lfE5ojPhEKUqs1Ra98gwNd/5Xu6/BxRQvFhhLeSE35d52XReIl6PlljEbYhAG6dNNcXZE+FFHf0rz3yo8V+IImAxiKA1Qs4qeJ28TqwJQznOaf6acnWjNMutMAn44+/rK3goHlPFY5bBEq+aTjcrBXiZhYAbjZjfJ2lzNf7gJKHJTQL/VpV9gx0hsQxK6l77qFLrBxaqLTu+jYbCUIWbke0rQ1kcIz2HG3weA+UHATmOCRsysD/ 32WvD15T vW1Jo8a47w/KEtp6RUmMAPeYuVbbefrR8EWJOe98QhB0jyzvbt5H//RuCPAaInT+sKtZPc8rOe4AXPM7BVslRHYz3wVQgHSMvK/wVAI6PD17mI5S4EdbJr/f8slz0OokaCJ7dLTheooOXEoPnCca2Wp+r/KjG28cWDM7CJo7MXb4b7/zjmXiMclniL7S8WZbFANCl0cO4jtFRJ/hi+4wJt+A3dzADANMn+jr7npuiBIUXXSApHUmF+u2nGXQBxLrRKxHPF2a5lmQO43b/Y91cUyXmgn+CseRiWKJlx27U7/sbfgVcEMcFOY9NMlc/dTQiOm7LXw9X56WPe6FVRYthLURnlQ2RvGA/07ULryDIrDtngE0ZTMx4QhGXr6fA3qCVvyAwtXHOqTkUMn3BBuuILip3TA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed 18-09-24 11:37:42, Frederic Weisbecker wrote: > Le Tue, Sep 17, 2024 at 01:07:25PM +0200, Michal Hocko a écrit : [...] > > I am not objecting to patch per se. I am just not sure this is really > > needed. It is great to have kernel threads bound to non isolated cpus by > > default if they have node preferences. But as soon as somebody starts > > offlining cpus excessively and make the initial cpumask empty then > > select_fallback_rq sounds like the right thing to do. > > > > Not my call though. I was just curious why this is needed and it seems > > to me you are looking for some sort of correctness for broken setups. > > It looks like it makes sense to explore that path. We still need the > cpu up probe to reaffine when a suitable target comes up. But it seems > the CPU down part can be handled by select_fallback_rq. I'll try that. THanks! Btw. when you are looking at this, would it make sense to make select_fallback_rq more cpu isolation aware as well? I mean using housekeeping cpus before falling back to task_cpu_possible_mask? -- Michal Hocko SUSE Labs