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 3A204C02198 for ; Wed, 12 Feb 2025 18:14:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91906280002; Wed, 12 Feb 2025 13:14:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8C8C8280001; Wed, 12 Feb 2025 13:14:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 790D4280002; Wed, 12 Feb 2025 13:14:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5C365280001 for ; Wed, 12 Feb 2025 13:14:40 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1B11C804F2 for ; Wed, 12 Feb 2025 18:14:39 +0000 (UTC) X-FDA: 83112093078.11.6DE77A9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 5BA641C0019 for ; Wed, 12 Feb 2025 18:14:37 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=a8M8aasG; spf=pass (imf20.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=1739384077; 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=+Bo+1GFoYp0JQjjgCT3qOtV1wlOmaqbBxjS9dDoIa98=; b=ztHsRtyf8QgrX4r/P7cd/8fBxbhwS2TUwoXfkJ5zU4HBrH5mfEvh6EnRGcLbtYQ6yYuD+r fm4ebyK7n91oX3yeWSPUCDNd7FdGfaun0P9md4ckTqEnv6u3O1Rmgoca/f6KFfm1HaakRV cpht4xl/knfeH/oIkMHytWKoqsznUXo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739384077; a=rsa-sha256; cv=none; b=HVm4LX4E6Vzj1omTe9O1EDC9S3vxnz5gS1sctLkCve+5RzNOlre6x9UkXkWZt50iq4yktn 8+DOPAGIBQEVP2Scy7P+OP/IXcr4aU+rRK2pQrIIxf+P6if0X8WL1lpV3eEgRH0K5Y+0oc czeLM6QnlVTbv2nXmhSFV62OM2XgkaU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=a8M8aasG; spf=pass (imf20.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 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 05D075C4D9D; Wed, 12 Feb 2025 18:13:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2140FC4CEDF; Wed, 12 Feb 2025 18:14:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739384076; bh=OzqjcEyZwG+WEGrwy6I+hrxWZBXusE11+Xm5A2cAxMs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a8M8aasGpl3m9DKYMQ+BCoXPdsaLq01KB5xDLVxqjhQyvrn/edXaft3pTcazDVeks 7yrRN3p7tyNIf6+vXJkfUXtHLb+rdQdmrLKTRGQZGiIMUd2Yfihfs0GRu1UNpSxPE8 rFH6UtErLR2QoIE+2k0T0ufH1wHkdwIJ8t6FJITBPtANns9djmuL2QG8z+LF3uAmy7 nH+7pXLBln7MjLq6abTTUZ6IbFb8PSxn1BtCzT+Rp1F9tkdTEfOQMNt6Q8pUa9NRwS 9X+XueWj94yeOpnxk7eTvAn2RawKcm+ehgO4DC0ak1OMu8dv6DxJZRnKiGN4Ad9gfn tbw9oR8No68cA== Date: Wed, 12 Feb 2025 08:14:35 -1000 From: Tejun Heo To: Michal Hocko Cc: Dennis Zhou , 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-Queue-Id: 5BA641C0019 X-Rspamd-Server: rspam07 X-Stat-Signature: rny45zo7b76f7893hjfodou1crmpyo4y X-HE-Tag: 1739384077-571551 X-HE-Meta: U2FsdGVkX1+nkqSXV30KQUwYn+RECUE92sIaYT2fVKIZO4QRr4bW22vVBUP6Avd6q5iG4LdkcB81F5Tpu5PPVulGv4009naB6Nb73ReXVkj1fjSgL9ZWbIIjuJThvbty3NkDWOvW8AzTsKFJq+fFKDEpqZikOJp6iBcxxcub12kyigWF3BV1HuBugk53K5PozGE820WtPkuZC+sSaXJZv8xpQ7h3Diw9rmX+7To20XpW4o3PGqPNLy89M7taX0dF3oyzqmOQYJ0ArMRiivouKVxwuDIMZxngZLrWY7j1AlhGOm49ByN/ilZdBQl94kBQOT2GE4J4hu+UYOj90QMmpgBGsIVVgOfhkPjvnii2JoY1xnt1OHJBjhS9K9cm6A2SbdHqf8hcalU/7BnwD97tN04ryqUqhboYR61FCcP1xKylS3NTzdLl3kmJCC0076w+Ah9+vMwVn9ycU7DhMPUWjznA22CMMpUNeinwgamxW6tg36DFooWlVYRueYgGKWBBB7xG31OHT14gysrUWEoOJhyYoXj6nfnqocQusWR9B4TcmyRFfHDiu2Ph5VeAPRp/gKNYjp9rlQMEKWDID8agEqAU/WR28L02jEr6dBJg2nHP8lNwnKgIHADH6TZeacwquqwB872F2vMz4Ywic28Km7I2GbhL5xvM9Z3wv3ElF2DYfTH1M/W371sffVIKps2IDmWLUMmb+is4pCsIzYRekePOG34R71uRSogN4Fs5nGvxuBwD7RIz0OG+unbhGMiX0iGSk6J7o1NOrwSXI/rXT6T+dp2qAJ/vipBzM5fILtygOgR/L8wFv99409s5hU6iAbonFmm3ctrpq8BH0rhONkTQE5Qp761aP/m1l8P3hh0rclit3oUYk0Nggsq47GMbWQL1dlhGyIX0ASXBz7nb0Klv9tcZWc6RlwpamYJy70ARv4/E0tNi4AqqWqxcFSJtVbZJKdypvGuqDe76Nre YytIsycp WPlH3P2C3qoW6NX3DkL4BsIL96D1EkM31VhuXD3pBhwSX4ctiUvcgkDM4xaK9pMDwl6R4k4g7t5ruKGHeozEGdxKtwTSJXAcOWHJllyt2eiKObQeDPVlLgkS0xVMQhlIb3fo2lDsE3QqcrlTs2DxDpDje+yZQQw5Oip8WW5nno/M/QSAR2KdWOvyjf83meMJ9xj2S8sl9YE4Y8ONYruObCha+4Q== 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, On Wed, Feb 12, 2025 at 05:57:04PM +0100, Michal Hocko wrote: ... > I have gone with masking because that seemed easier to review and more > robust solution. vmalloc does support NOFS/NOIO contexts these days (it > will just uses scoped masking in those cases). Propagating the gfp I see. Nice. > throughout the worker code path is likely possible, but I haven't really > explored that in detail to be sure. Would that be preferable even if the > fix would be more involved? Longer term, yeah, I think so. > > Also, doesn't the above always prevent percpu allocations from doing fs/io > > reclaims? > > Yes it does. Probably worth mentioning in the changelog. These > allocations should be rare so having a constrained reclaim didn't really > seem problematic to me. There should be kswapd running in the background > with the full reclaim power. Hmm... you'd a better judge on whether that'd be okay or not but it does bother me that we might be increasing the chance of allocation failures for GFP_KERNEL users at least under memory pressure. > > ie. Shouldn't the masking only be used if the passed in gfp > > doesn't allow fs/io? > > This is a good question. I have to admit that my understanding might be > incorrect but wouldn't it be possible that we could get the lock > dependency chain if GFP_KERNEL and scoped NOFS alloc_pcp calls are > competing? > > fs/io lock > pcpu_alloc_noprof(NOFS/NOIO) > pcpu_alloc_noprof(GFP_KERNEL) > pcpu_schedule_balance_work > pcpu_alloc_mutex > pcpu_alloc_mutex > allocation_deadlock throgh fs/io lock > > This is currently not possible because constrained allocations only do > trylock. Right, the current locking in expansion path is really simple because it was assuming everyone would be doing GFP_KERNEL allocation. We'd have to break up the locking so that allocations are done outside locking, which hopefully shouldn't be too complicated. Thanks. -- tejun