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 2104FC83F0A for ; Tue, 8 Jul 2025 12:28:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 94CAC6B0314; Tue, 8 Jul 2025 08:28:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 924066B0315; Tue, 8 Jul 2025 08:28:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 813BD6B0316; Tue, 8 Jul 2025 08:28:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6D4A26B0314 for ; Tue, 8 Jul 2025 08:28:05 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id CC66B10B453 for ; Tue, 8 Jul 2025 12:28:04 +0000 (UTC) X-FDA: 83641024488.19.093F22D Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf26.hostedemail.com (Postfix) with ESMTP id C91D5140009 for ; Tue, 8 Jul 2025 12:28:02 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WBEMmjpv; spf=pass (imf26.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751977682; 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=0DPfjyuVlXXsi5ftQdkUNQRfIJjJbSSTbPWyxHVJT3s=; b=c70ovftnfhirSyPQdkxmXY4ILUCy4tRONqOJlVL7x33hNbb32CHI4TqAT5Eq0BGDQeOq+F 6DenkkvtAo5KeGXQ+JbUYoUy2irSoMxBILdpoKl0VU6bEVojVfFaZbBoFBIe/AqFSX92D7 AAGu9DNUPV2NdTEi7ZUU7UehLaUvdao= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WBEMmjpv; spf=pass (imf26.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.175 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751977682; a=rsa-sha256; cv=none; b=mIgDi/bPTUzuKWbkPu8gDkvpqNf5meMWq7RBBTWt91QXCioYHW0oKvxv5J2NaK8x4YdYvr kwm6fC534ocO78Vt9NK5I4SAaSW4EGgPfG8n3t7G6SFwzvAjrHZI0mpz8p45vobuYwnOnw Cvprhj+sJ9WPQUPm2buvyHVt8akKGgc= Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-32f2947ab0cso18799811fa.2 for ; Tue, 08 Jul 2025 05:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751977681; x=1752582481; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=0DPfjyuVlXXsi5ftQdkUNQRfIJjJbSSTbPWyxHVJT3s=; b=WBEMmjpv2wkxJqzNFtixBfpz6qEzgaEY+OUc5Q0srapZs6dK0D+5BUb/D//+G1RcAW nmpDeyuYNNtwgPSOpfbvBNZFuShZBNtU3/96YhKm+m1Aot/j87u4ygcf6Moxxe+X+xy7 8/ne5tp2+vEEvJZQPC+gdjdfHWrTJJl0BNv9fmVgtmSXDQRCrCOpCFEmXRsvibMJ6cxI Y7GKyHUkeokcpGywRks/5MiC28ieguYtMvAYagLOqy5YHKvRcI99GU6PsCCXrQgHQwi0 rcvMzI+7xQX9fcbB7ruPx5mISo4sVnkGKwnmQ2q0Dx3jlPa2BbxLc7TBctgJJ5mbsgoM SUNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751977681; x=1752582481; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0DPfjyuVlXXsi5ftQdkUNQRfIJjJbSSTbPWyxHVJT3s=; b=jnM95XMdsHlBEHp5VYElbwFSIVx9k2GgDmiOtCw4YA5QujneZCVMtcIdGw2BMaBFQx paaUPuu8FzIiTbT9zl7mbwiul3ePElJmp++UC5++QpfD/AJKQcoUAdhwBKs75iM2dinb DxPNX8arIYjFyAaENNG5WEKH/ngEE1HVSgMwbDhv3iPXgUUTBOW5Ih3Qktq/BMr16djS ZF+qw1Mra8rIjLjeisbJZw4deWQkL3a+v6CIn3+TAi5CFd88ovSOksa3PSnLJmixDmtW Wf/Mo5SHiM19rZRbPpj3Bo4a8enTAda4pEaKdEJRjKGZN3dxbViVF8wTzW+YEgUEcRoX J2uA== X-Forwarded-Encrypted: i=1; AJvYcCU84MmjNcDxpjGYq6A+QGIYwaERyMGAutL8PAydUZaB7mQY1PIi6xJf0Q49xbh7mxpUZbvJpai+yQ==@kvack.org X-Gm-Message-State: AOJu0Yzp3qXWXXgRpt5zHbSk25+YBsfVCK9nwgyD7XUWd41K6JwSk+YO 7dEneBKQcAeGucvjANZr3Ccb672GfzPSS9EScYRJhqKy66d8LSoG3ttz X-Gm-Gg: ASbGnctjYX5npqpbMtzGuaOWe5IeeFzoIj6go/U2DfZIQa9OfjlA1qgFshHQFNGpJDV ImQbgbr+pBFrNowYGyviovpKumHmPdpkrMRF4AYEvF1ZRico6Ba1cHMeY/uWXXKxKXvDF46F5U7 Evs6sNFq0lmVwInMlVx4Vuzxt/gCDugyjMBVNF8/pwZSJayKGVwRzindOJ0avGqrpk2Uvq8BqQS Gh9NK17jDYMvYVBfv/cuPMxUaqKt8dmjnshyoCW4SVIdR2SSzNrBFAOtW+YwU6UxLRwiEbrFuoZ C/w3jqK52qaTEH+GG/mpvsBpnRt0+6NQl185yfIkeEjF5D5nutLVUW8oMnQOAILklD7gd5I3WLs JniMYNhFc1XY= X-Google-Smtp-Source: AGHT+IGpc6z8fSUIrwMfew6wZtyxhbGdxLVk9CwZmf1Ma6HTtQ5CZu+hNcg6avruLSsKeeTuxQBKWA== X-Received: by 2002:a05:651c:10a1:b0:32b:387b:de0e with SMTP id 38308e7fff4ca-32e5f568d0fmr42522861fa.7.1751977680464; Tue, 08 Jul 2025 05:28:00 -0700 (PDT) Received: from pc636 (host-95-203-1-180.mobileonline.telia.com. [95.203.1.180]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-32e1b1216d0sm16097591fa.71.2025.07.08.05.27.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jul 2025 05:27:59 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 8 Jul 2025 14:27:57 +0200 To: Michal Hocko Cc: "Uladzislau Rezki (Sony)" , linux-mm@kvack.org, Andrew Morton , LKML , Baoquan He Subject: Re: [RFC 6/7] mm/vmalloc: Support non-blocking GFP flags in __vmalloc_area_node() Message-ID: References: <20250704152537.55724-1-urezki@gmail.com> <20250704152537.55724-7-urezki@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: en6xo7s8z4ufqnxsmcctpunbjj577izc X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C91D5140009 X-HE-Tag: 1751977682-715903 X-HE-Meta: U2FsdGVkX1/j54GolNVbZAUKBC/3fbc0SKZqaVMrwimyO0EpIxdNMmKqJ/auXJ7dBIa1Nf0OoaoyMcTha1t0VV/ooHOTAP0Ha0wfyUwSrSaY70LXQm202XNHiZr0ih0MILLpqUkd2OI/TZ9YnWgYXInHaGGXdzxVbzMD/rAD4QzPUXnRQgd501OlcR+umLElJ+VsDko2a5PymubdySvLAre/M7ZW6CLqBPccZ248H5q7mEUlZqxtIvS14XEEaYLXt4jFRb+94bbmlS19CG2v/dGipx/aAMBZRzNUgCJkLLP542oFT9p9ocLZQpI9gJakkxaVat3uEmNLZ4XksCd4xronQyr8O/sC0ChqZbuCfNwnkVW2oRk4m5+zFnZIwo2TeG0N9HDWsXQi6uLt2mZQNYnkH+PTfgESfS5oIwfVjlc9EZ76j7md03QGYYmvB3VQeVJh2wBZEAKsD3KBE4JfLxCW/qJh7yWd0CbSASaBgegBvzToQsIvBAASrfKETRnz+DHc7A8OFxLxekqTl3u8kgykt5UEMUqsi+EAnIeeLfHt5sucJpqQHECBwtPxMR65HN6p7WHk7I+7IxuLdbcDYafEBoq0Er2R0W/RrcMqdGrvjpa/8cJM5q9w2lqHo+WYnG+vz52P1axsyrW+N6b7cVHAhWIKLkzfzQp9yJJZXJSbH9ptAGzQcXhpU4kysYXoU/yUL74g8hbB1iWyKqrNYT9Z1+YPnC8v/n5gV9POpiq0/q5OAU3bX22+uE/4RAQE2Hu/KQxGndxBNnwF5UNR4xiDwae5YerZ7Hq3XeQNmenjTH9SKFpSqyMOo0mVh+MaWAK6xP7Gtuvq6JT1E1HazxOvQqDQs+n/goui82tTKbpkf5bJmzAZjZZCzPfxyz/dL7eo2zMcnKjzgYguMI+EenFU5idvEJjnMTrwtEFLSDCOozNei2K2swUM0vs/vlJn4T/5rpMtDgXDPVO1nOX c9FprJa5 UCYMu+Gxm9pzL4QGByuDdaz+iODKTzRmJmjWYYROZ+u2ROUw2mAVnKqzrIPc/KLATM7zaxzWyCy2V88M7B6BV7W54CqjuWQ/SQ7eb4ATDGmj2hAjTTaShyIS64tOs4wVrEJy0u8bwwua3mEwvxZBWcCoq6VT1EAnP6dFtRSd0ifc+mpZQDQASYV8VHMblTf1CVETWb4ssnn8DB0qO/QB1O60NJoGBu+PFq3iLhikKWFWIJNh7cKf2ciXGZXwH8vXUwuHhXZcFKV9i0+aFLq40L8QqiDMf38cQxrt9nD8ovKxfVuWRVMGhv1IP2oUGWJ0aOFGho6uuwoA2xwiLNnunyL5kP4Nj6cWKjoQ/82KF0lW0PVNWdNDjunceNEvwMPAQZcb9va75C6/C5P05w2s3eFwK/434VcnPulOc1nmGPa6f/djvnruw79O3Qvfi8YbM9comPUClu62A5s03ySMHPuCGspmF/Ua4jULj 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 Mon, Jul 07, 2025 at 09:13:04AM +0200, Michal Hocko wrote: > On Fri 04-07-25 17:25:36, Uladzislau Rezki wrote: > > This patch makes __vmalloc_area_node() to correctly handle non-blocking > > allocation requests, such as GFP_ATOMIC and GFP_NOWAIT. Main changes: > > > > - nested_gfp flag follows the same non-blocking constraints > > as the primary gfp_mask, ensuring consistency and avoiding > > sleeping allocations in atomic contexts. > > > > - if blocking is not allowed, __GFP_NOFAIL is forcibly cleared > > and warning is issued if it was set, since __GFP_NOFAIL is > > incompatible with non-blocking contexts; > > > > - Add a __GFP_HIGHMEM to gfp_mask only for blocking requests > > if there are no DMA constraints. > > > > - in non-blocking mode we use memalloc_noreclaim_save/restore() > > to prevent reclaim related operations that may sleep while > > setting up page tables or mapping pages. > > > > This is particularly important for page table allocations that > > internally use GFP_PGTABLE_KERNEL, which may sleep unless such > > scope restrictions are applied. For example: > > > > > > #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO) > > > > __pte_alloc_kernel() > > pte_alloc_one_kernel(&init_mm); > > pagetable_alloc_noprof(GFP_PGTABLE_KERNEL & ~__GFP_HIGHMEM, 0); > > > > The changelog doesn't explain the actual implementation and that is > really crucial here. You rely on memalloc_noreclaim_save (i.e. > PF_MEMALLOC) to never trigger memory reclaim but you are not explaining > how do you prevent from the biggest caveat of this interface. Let me > quote the documentation > * Users of this scope have to be extremely careful to not deplete the reserves > * completely and implement a throttling mechanism which controls the > * consumption of the reserve based on the amount of freed memory. Usage of a > * pre-allocated pool (e.g. mempool) should be always considered before using > * this scope. > I am aware about that comment. I had same concern about this, but it looks like i/you may overshot here. Yes, we have access to memory resrves but this only for page-table manipulations, i.e. to allocate a page for 5-level page table structure. We have PGD, P4D, PUD, PMD and PTE which is the lowest level and which needs pages the most. As i see we do not free pages at least on PTE level, it means that an address space is populated forward only and never shrink back. Most of the time you do not need to allocate, this mostly occurs initially after the boot. > > Unless I am missing something _any_ vmalloc(GFP_NOWAIT|GFP_ATOMIC) user > would get practically unbound access to the whole available memory. This > is not really acceptable. > See above comment. If there is a big concern about this, i can add memalloc_noblock_save() memalloc_noblock_restore() pair to eliminate that concern. The context will be converted in a way that it drops __GFP_DIRECT_RECLAIM flag. Thank you for your comments and input i appreciate it. -- Uladzislau Rezki