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 179F0C282DE for ; Wed, 5 Mar 2025 18:49:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7529728001A; Wed, 5 Mar 2025 13:49:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CFA628001D; Wed, 5 Mar 2025 13:49:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5978F28001A; Wed, 5 Mar 2025 13:49:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 395A7280019 for ; Wed, 5 Mar 2025 13:49:03 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C40DE1A0683 for ; Wed, 5 Mar 2025 15:10:22 +0000 (UTC) X-FDA: 83187833484.15.8CA61E6 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf03.hostedemail.com (Postfix) with ESMTP id 95BA92001B for ; Wed, 5 Mar 2025 15:10:20 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bdnTYT3F; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741187420; a=rsa-sha256; cv=none; b=f1McQL3RT3XncOuX5RJuBMe8jrJh9LSOgVQzpsmaQ1sq1W5qqEoD0ls1/ed/Hx2LeIMGHS PDKo4p9+LX76KEnP8nj+WXZ3jAluVzF2dpWsLbKRXw/UWgKSL56lZ5OpgWwNAUJC6svfsH 8q+y37AokFjOYhcwkZ5khchTYE7btl0= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bdnTYT3F; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf03.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.51 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=1741187420; 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=nb3IwvZEIbVMVABGFoJs3pODTanC6EEzp5rqEbnLKAY=; b=WGRnz44RlRKjhhQheOqniWV3BEruibumjyZItFG1XdDQI46ANOanv+jdgPAGsEzFwQKSyY vnfwtKiA9oTbobwbs8naharvhpk15mWrr4cInEcmS0iaQUXn3q64/NRdYVVWwOKp7tjctD P+k08AygQeFnyIPyrmnjcFo7QizBOTI= Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-43bc63876f1so27617475e9.3 for ; Wed, 05 Mar 2025 07:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1741187419; x=1741792219; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nb3IwvZEIbVMVABGFoJs3pODTanC6EEzp5rqEbnLKAY=; b=bdnTYT3FM39V4rVC9CCjzogScj2+649KlDqJtQCWEwcCZ/n45Q2Tc3sj9ydcuqxqM8 soNdMg7c7OWgPI0Jy+g3W49kdJ9fC255A/GrP7M1Qz34tmtNhr4a8536n6sbpdB4paq8 tAjYydjNaGrwpsgGT3rNr8T3r+LzfP6x03394JZje7EuHzUW1K6rZPfVWmviPKuGgsiP HGaOh+k6nvYxegXVA9i9L4JDX3cn20Ko4cnPZqb/fjhq+hioujU70unHnYgDMQfMcZ6M Kdn2GuFTR58Re7bA+XIxI9VuDWQ/R3rjz2tQJVBpbbX4YiWgmf2gklaX3tbu2Vh77tkA b0FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741187419; x=1741792219; h=in-reply-to: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=nb3IwvZEIbVMVABGFoJs3pODTanC6EEzp5rqEbnLKAY=; b=hWMczd2ixdBLzaxJbp81BiREAbhVSRIcBxGKwB3h0nJvPf0/L/yT9+tcykQ0ndmeWs W5IN4qL4wXdHMjxudoA7N0chqbjXiM/uOaz8RVg/f8TQep9lonqF1MQu8f6QodwS09v3 7lATIAVCS5OVvxYO6JMwkA0MM+7x262d5C3ZuSx3DpdWG219BT/nDC6E87cq5QqXf/Xz HPCfqy+8dpIb8lT5aWxfoeibGO457jzNFBHdu/HyudUQF+S4+jEGFdx9AkY0ZcLgs+Yj Wn2qKZQfo4HUTtduFMurRQ6neyqJzXmx3JmijfyTBdKSTwzR3AXUhdByybwYzVg/KDj5 AZDQ== X-Forwarded-Encrypted: i=1; AJvYcCUh75T+rzAxeByHKw4F3olqEb/bA6zAVANTA2kR8sjcS3CK82wlBzjwERnoDOIEFa4O1vzbyZKq8w==@kvack.org X-Gm-Message-State: AOJu0YzlqFbaA+PZDSh9hrUKxeTJQx+8QwFtPsCleTEEGUcqomy19jt5 cxyYKqj+WCjQUFbTKFET+lmseSIAR7AUfbk5yobFHueoPKSeylU+hcVxZP1EAiI= X-Gm-Gg: ASbGnctl1k8ZcINZXy7kHST1Tm/RZ5gN0w8PB0COXo1a8mpvK2yUYiAG1PYEZQDP2W7 Fu/Vv6C4WFpaQQorTjkNRLu196zlsNQp82hpi8D1Txjos/Rhu62Y47cHCuPYI32IFj5xtzPrlGB yfW1XPROpWK1gKs03XOq8RLFdCa3ZDwM5JiaWDgxs18YSbNurtSouz+Zef7Eul6yDig6x9vtJt8 2CtWuqnFHnmI+ThtfSKVD3wbOgBbsYhpTY3OTOZvHzRER72hR6P1RmgKEjXU3yUPR5qdDPOg/An HFdS4wk339IsbVSFskquVN0ZRCzPCIRDDwC1XP2IsOawEbLNYXb2HZMbjA== X-Google-Smtp-Source: AGHT+IHY0XWIZIrtX7/phGcFfq+MLz0FI2euq2tdU8kbJkxFDE3E48w83KNAkvsZm9llZmZhdx3qVg== X-Received: by 2002:a05:600c:3b2a:b0:43b:d251:7aff with SMTP id 5b1f17b1804b1-43bd29d71c3mr24143305e9.23.1741187418796; Wed, 05 Mar 2025 07:10:18 -0800 (PST) Received: from localhost (109-81-85-168.rct.o2.cz. [109.81.85.168]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-39122da6cb4sm2115955f8f.72.2025.03.05.07.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Mar 2025 07:10:18 -0800 (PST) Date: Wed, 5 Mar 2025 16:10:17 +0100 From: Michal Hocko To: Vlastimil Babka Cc: Dennis Zhou , Tejun Heo , Filipe Manana , Andrew Morton , linux-mm@kvack.org, LKML 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: X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 95BA92001B X-Stat-Signature: 99yhstexccaoia5nnnabf35n85fc6ckt X-HE-Tag: 1741187420-291036 X-HE-Meta: U2FsdGVkX18Ur1yHFbehaSfUSNNAWOrukpP+BCxhIWGOpPPwBnY3OSZxzK1fziq04uvY9dOhkNegFGPkx99HXfvOvOdeji22JDBr1yJL9vs7n3eL35vQ6UOnM88hdscYwrVJHVA0EGmzcQHBouHlDfLakJfOpfEnxdEvqDJXRg2GIKwHujEkEAIi5/ftktxqzyBVYu3W8tN/mSNOBGQ9j2OhTd2dMEFD//C53VgFo9CFgR79YRjPp57dbd6dfrzLGB7s74RnuyFE8Eesv7DsCzapXhWuwbJ/mp67vQufsKXASU7FkrHmZkPZGw7vfP5vTMDJvzHLNBOxyc8FMlfJ7IdXBuNRgpryrl8Rt4oVqm57zXtQ7UAO/clEOyj7wR9FG7smqLOtlZzQUODFMFWNP415X3rT5im9BlBjHvlpjamuJTXDSVLO476sZy8cAYyki+ZcjHNz3X4//cQatEPhZHIFNBgz8z3GSZj/dOjD1VKJHaPzTjg4xgqQ1xKbuU5Hu9W6v0puXtyOgLAzgbHKoTWAw0QYjnv/vTfIKJM3BpjJLa23MMEWsnBYyL2xN/uf+axj+dXFxgPm5y9MSi+ykysVg9vC45oXbuf6sePCKMZ22ZwseDXOAckmFBjknobG/BLQrrEWsR03qChvvrDYXWLgGU6k+xR7A3uEy9fPCUI+dSUudl0Jl9EsIVkK+q7Dk+nbzfyRlrtcju0+VkrPS5D9d/JbR/C+bIRG/zb7efl2BqV3X4Ru4bU6PEIEiS6lTTqBkBgZu498vnReK//54Mc0voDFR4/FWZpxu3j//sMlBPiNSPEL4eR+eDq+QgtnYO7sZkcVgNrPH8+F8bGuHzCiMxMMoMKETJAN8v6pNNunSa7SQGSfjBuNVui6mPtf7j37w9BwDmo8j/JVryqD+3qrRuRqkWEbJhT/53+RbR89WJNRmLChztzGg76Cc2oCdN753CcSbmhmHmY4fKB hoIc8Efy OB/HPcBoQvsY85GZeHbRxDaHjbQ+tTAxwAl7UjR/YJi7QCOZ11eiOk/LmyraTOowl/hFyYYPtcXFCNqjH3nLRu1Eh4d8AuyDNQKVVzQU/ThUYuqmWybIcb3lAyZzZoWWHfnjUbHmRg1gvGgZlQDvejok+CWwS4hdP7r1cxoa65MuEDj3HotvWdb9naKJlc3bFd6rYP9Usxq7/y4fcZ8dAeEwEh8Ya5kWHgXGR4asEKfEyD/Oe923/gyEmnGJ6xYk1hU8kYZWgN2EK/eZhi3wlqhIP+BS636qkKTnXijEsw1SMgRxvBF4tNn21ZajWiiWzRZhy X-Bogosity: Ham, tests=bogofilter, spamicity=0.000415, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Sorry, I have missed follow ups here. On Fri 21-02-25 10:48:28, Vlastimil Babka wrote: > On 2/21/25 03:36, Dennis Zhou wrote: > > I've thought about this in the back of my head for the past few weeks. I > > think I have 2 questions about this change. > > > > 1. Back to what TJ said earlier about probing. I feel like GFP_KERNEL > > allocations should be okay because that more or less is control plane > > time? I'm not sure dropping PR_SET_IO_FLUSHER is all that big of a > > work around? > > This solves the iscsid case but not other cases, where GFP_KERNEL > allocations are fundamentally impossible. Agreed > > > 2. This change breaks the feedback loop as we discussed above. > > Historically we've targeted 2-4 free pages worth of percpu memory. > > This is done by kicking the percpu work off. That does GFP_KERNEL > > allocations and if that requires reclaim then it goes and does it. > > However, now we're saying kswapd is going to work in parallel while > > we try to get pages in the worker thread. > > > > Given you're more versed in the reclaim side. I presume it must be > > pretty bad if we're failing to get order-0 pages even if we have > > NOFS/NOIO set? > > IMHO yes, so I don't think we need to pre-emptively fear that situation that > much. OTOH in the current state, depleting pcpu's atomic reserves and > failing pcpu_alloc due to not being allowed to take the mutex can happen > easily and even if there's plenty of free memory. Agreed > > My feeling is that we should add back some knowledge of the > > dependency so if the worker fails to get pages, it doesn't reschedule > > immediately. Maybe it's as simple as adding a sleep in the worker or > > playing with delayed work... > > I think if we wanted things to be more robust (and perhaps there's no need > to, see above), the best way would be to make the worker preallocate with > GFP_KERNEL outside of pcpu_alloc_mutex. Yes this would work as it would break the lock chain dependency. > I assume it's probably not easy to > implement as page table allocations are involved in the process and we don't > have a way to supply preallocated memory for those. Why would this be a concern if the allocation is done outside of the lock? -- Michal Hocko SUSE Labs