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 47109C0219B for ; Tue, 11 Feb 2025 20:55:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 965AB280001; Tue, 11 Feb 2025 15:55:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 915736B0088; Tue, 11 Feb 2025 15:55:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7DCFC280001; Tue, 11 Feb 2025 15:55:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5D1826B0085 for ; Tue, 11 Feb 2025 15:55:25 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D7C5B1C7F79 for ; Tue, 11 Feb 2025 20:55:24 +0000 (UTC) X-FDA: 83108869368.08.C86C90C Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 47E23100002 for ; Tue, 11 Feb 2025 20:55:23 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TRe+uaTp; spf=pass (imf05.hostedemail.com: domain of tj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=tj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739307323; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mIiJNpImyGqz4JZ8WnPeaH/DrdTZw2RRo+O6wLMC97w=; b=NIII0W8QyoQ2EqwgeJ9IW1RX2UU5ErYrb/QmEIz+pUeAINXq36NBdWPXvgJkN7sXr/expY rq1/NXlOZKndSeYKz4PPbPbPFdjW1SDPlEo9LKc/PojX41SyBTr8aUX2xbr/NJBgunSF24 Y/w9KHiJ6WEpr5tHtkCGu77gvXPsH+k= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=TRe+uaTp; spf=pass (imf05.hostedemail.com: domain of tj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=tj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739307323; a=rsa-sha256; cv=none; b=CZW6j2kZrr+9QPESeh5FU9aqDEw6dDi3eM6ktZqjIY02Z8kryoikOmtYej7UAi/wQvWl+g pW1p6CCiPhNie3dPAb570SUaVOmJqRCNZD1WclJRDwFtL/Dqg0uKNofFRdrT+SrD+ZChGH ToHlVpXXAoFgmnqGQyNDtqeJAd6eAQU= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C973C5C55C5; Tue, 11 Feb 2025 20:54:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3764C4CEDD; Tue, 11 Feb 2025 20:55:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739307322; bh=MAVRVwvKPz2MTsRCiP/+SknMX+X6PxyJk7h5D/wVeJI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TRe+uaTpoNkO77iz4yUDQnTow/GlONddlvOVnFyupzlv4+EBLSA0PZVCqVdZfdObL goakqDmCMwQmksT0PUHVm9tDyrsgIJOcrPRHNXHOMsrYUwzWrjfxnRP96MoHJBAu7W qp3esDDaUVIay2Ctr997qxBcuPBL8NWaFSe/yNZilclqHl7ey1LbG4RldR8OIzzrYm i8DAGnghfplMKzv8673Ky+yTuttOWcFIHa1RKFyeVWZvZ+Et27/vniahIveasChuVX LF5AqK/1jfJ7xRsUvc9FmEoQLwEhdgbYC9NOqD2YtspIIdT/POla5BdhJAH+/SrwhC m9VYMuCdxU9/w== Date: Tue, 11 Feb 2025 10:55:20 -1000 From: Tejun Heo To: Michal Hocko Cc: Dennis Zhou , Filipe Manana , Andrew Morton , linux-mm@kvack.org, LKML , Michal Hocko Subject: Re: [PATCH] mm, percpu: do not consider sleepable allocations atomic Message-ID: References: <20250206122633.167896-1-mhocko@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250206122633.167896-1-mhocko@kernel.org> X-Rspamd-Queue-Id: 47E23100002 X-Stat-Signature: ryq8xqpzp8gnh4bi8wykde5sdw8nrgg1 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1739307323-977632 X-HE-Meta: U2FsdGVkX18QUtrw6xYY4L6lJgHBV+Vq2oqR7sSu6+dBCaQOvP2hmyjGJjeqXlErxdvAyEFFT5pneyU63KCXj95IQdB1xb3AXeSTZq8gdByl0DdT8aYseDox6FvIZNdclZdjA7mdYu75ZejKzhMF0RXF8Oq2KvXtYK7M0vZ5TNp9MpWULCbB12RWuAHC7idvGfWSBJHxCIPyDhX9tH3IzY7kJXtypAcx89URsCsDMTVbQ6Pt3PUFxvV6sHXGx5aTJyN0vn7mW2QQx8QX26wIaWvtVqCmjcGStqvunSl7eaUlPM6ATjE9z6dWlHbBLhV5YKoWZm84AB80LKpUHl6Q+gDI+q7sXF1Mf6dmqNmqqzs+OuPnAkoQPHPgBAzecaMstke0dUBUkeEiX7QJbev1FzsJYuAQT/rTihAMPDX8CFA0B4PsC0PWohzzoBKPIMJCmX+VfOnz5hDlXKc0SQE0uEkpuQl6hWoBH+02mqyQ6mr1k0v/kfS/7VxnFgC9DpJByDhPWzvJGVZFvpZ/7KdsnsME/5txnDXWz7zHnV1bVOfPpFvSagK7oVGPz7H30+CgIL/u16h+CvZxNqRzgbKOKCiPS5juWqxLC/KDo56VYe3g9/TA8RoG/aBYxJYzBiBYq8xfobEfa1X84NquPcHcAh5ZD8idNNWCFbWk6xu9ZOapQGwDLZG0KuHZHQRMqEq79Jg84ZAh5qY25y9Ki2fQ8TQNtxqmewb27WB3NkneEvubEYk1EogBV762TmBobRQJ9sTiat2i4B2ZgzVFFRvb4I6Upf3wyiwN7LTGh0Ph2g1SdkeP535PnVbVwMk6pTK9PCSdSL9H8qbPYTiBiy1amVH5YCQZVfkiPuDGplHhoVAL8Z/4hm97qzJTC9BKhhbX+951V0PRlTjf9XJpsIpCyHy5hue2JKtNLobMdPHZEIGInP+bBi07RG3abBqI4PjX4yOCcsGqv4aNCA6Ck7W gETx9P9K aaO9iAfExeE+MxVZUAgY4cEZCJIQjPDhyDdSyYLDsP6Mluw3++OeAPjdQL0yt2vMaAaVJ1y2s2DdlzcV0TGoVQYbi6jPUKoMfAV0ushWX7fsN0ssIaCrL5747DVQ41Qo2JFtK63OMZdhUSfFpy0Vso5wWbwzZKtkxnQ/XtqfZL7X4//eA5+RBCQeabHEKFvTkuwEZwcSrsgJMiFVCksqiCyWSLVsUoAtk7BkIb7s2rXQwyy8= 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: Hello, Michal. On Thu, Feb 06, 2025 at 01:26:33PM +0100, Michal Hocko wrote: ... > It has turned out that iscsid has worked around this by dropping > PR_SET_IO_FLUSHER (https://github.com/open-iscsi/open-iscsi/pull/382) > when scanning host. But we can do better in this case on the kernel side FWIW, requiring GFP_KERNEL context for probing doesn't sound too crazy to me. > @@ -2204,7 +2204,12 @@ static void pcpu_balance_workfn(struct work_struct *work) > * to grow other chunks. This then gives pcpu_reclaim_populated() time > * to move fully free chunks to the active list to be freed if > * appropriate. > + * > + * Enforce GFP_NOIO allocations because we have pcpu_alloc users > + * constrained to GFP_NOIO/NOFS contexts and they could form lock > + * dependency through pcpu_alloc_mutex > */ > + unsigned int flags = memalloc_noio_save(); Just for context, the reason why the allocation mask support was limited to GFP_KERNEL or not rather than supporting full range of GFP flags is because percpu memory area expansion can involve page table allocations in the vmalloc area which always uses GFP_KERNEL. memalloc_noio_save() masks IO part out of that, right? It might be worthwhile to explain why we aren't passing down GPF flags throughout and instead depending on masking. Also, doesn't the above always prevent percpu allocations from doing fs/io reclaims? ie. Shouldn't the masking only be used if the passed in gfp doesn't allow fs/io? Thanks. -- tejun