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 0DA86C83F09 for ; Wed, 9 Jul 2025 11:20:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85E546B00A8; Wed, 9 Jul 2025 07:20:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 80DCD6B00AE; Wed, 9 Jul 2025 07:20:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 723B46B00BB; Wed, 9 Jul 2025 07:20:28 -0400 (EDT) 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 5BC8B6B00A8 for ; Wed, 9 Jul 2025 07:20:28 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F153A140406 for ; Wed, 9 Jul 2025 11:20:27 +0000 (UTC) X-FDA: 83644482894.18.CE4E7E7 Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) by imf22.hostedemail.com (Postfix) with ESMTP id F3D14C000B for ; Wed, 9 Jul 2025 11:20:24 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EGBuVthU; spf=pass (imf22.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 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=1752060025; a=rsa-sha256; cv=none; b=RwysrtuSCo2UdvRq9WMFq2pRY8WSQzFQanJei6wNtVbV341MPLytooMMbbRZKZq1vcMUDq 8ml7Ku15MfluV/9PGcW2TvZ2VyG5hAmG7TtvAGK658QJbmk+X2y48qUrPIMoNUXo3bhUbM NOfE6RmYOE/C1I4+ITp4wV/l8q+cJ0E= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752060025; 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=txd42CVnl5W2pOlG8rm4KcHzy5Vi4ZE+YD5Q4QXw2ko=; b=DpE7xxMBxby85WVOdYvhf4CtB7tLOWZbOtS/vxzMKfrHAuO4CWIVXr1NP1AubFWJpeian9 +0EsuFrm6QTF7y5RKPOxY1zDBfZW7hnpy3aIa8R3+QnXyKsMhKnwKoyXaADdkVZTCLg7Tn I84ja6FNhRKSKhSBd3n9aAROreWL2SY= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=EGBuVthU; spf=pass (imf22.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.51 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-555024588b1so5365661e87.1 for ; Wed, 09 Jul 2025 04:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1752060023; x=1752664823; 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=txd42CVnl5W2pOlG8rm4KcHzy5Vi4ZE+YD5Q4QXw2ko=; b=EGBuVthUxMLFXLw58A5abJ1zW+24CxKWevePZ4CMINLauPTXU2zvTJqdey44co2iY4 aUU0Jucq6I0pNMoDeEEaZukU2lFOi+ptLEcGsWA0MrJjIoPfVCZWo6j0LPKSRTfvDL2N tZw0KA4HtSL8TiY4D/WJAb4q0LjCx75nPz1cAOoRsqZJ4yaXV4DFIZbaagN6AvzYXepM Jk6nm/+oqzpCgWMNR2YhxPwahzwGJF8cHhFCejKoRsLX9ETBBjUxvOS/4nBEoEbmd9pl RqaKUFFXpabC0a2adf22aGRFAyLL9apOw3TSBHt2p32FTpo4wDS7wjwtj2FfLdXEikb/ CmfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752060023; x=1752664823; 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=txd42CVnl5W2pOlG8rm4KcHzy5Vi4ZE+YD5Q4QXw2ko=; b=SErIHE3EU0rpC3npj+22mWIkZOWNHvm8iJt7TW44+g+kCgR86ZrbWURr9XdRoxLQIF 7y/tmx940E/0yh0mA2RWDUMsOLgsHfVeDgrwM+1B8CVWaBMuh5wZrSiBWlYgKTefmWLv Jvw8Y6yO/1bnvHSSZ+eFX42Z5l1sVX/S90IXIo3TvGmVPap2aicsqMpvTamKUsQC/lgt 9EChuC8/rV9FCMMw60O6gCV2K4QBsrcSk7MbiegXTOmUxi8XLJ84JcFSJB9+Lf1Tnph8 BlCqxITeZ8j3DbO6eQLys5btpevbQNpTXwiVUOo5qumv7+h3puXP2NuZklsxvIh7Wkqd 4Mmg== X-Forwarded-Encrypted: i=1; AJvYcCWq4Rug5UdkXJVAhXpXi260u/mvd/82n0l1VNe8sImOhXCEzR/lPoP5I6XohJOjVawEZ2wfZfjebw==@kvack.org X-Gm-Message-State: AOJu0YyNZTB5mMmfNfJIeLYIw9NPjJALIO0G4dGMnUef/MCyxSGIgv2e fxfwaLtRanEa6/9GlDKeN+gvA0W6vRwPaAlqFjufjf4gHV4OsUYZlkle X-Gm-Gg: ASbGncv/TkADsI7YhpmE1h++WaZuu+rneAopMj2sJiZGBs0Bym2yCJf1brnHyJpJ8Cc o/g9HGM5bItOqOEtoJYShJtpETb80O0AirlA9Oxq70kZ5WHo9DLymZoz3GZz8ONmoilwJwF4s3L caR/iMOLnKyDNCcqKCAUGm4wea3CJJBLT7bb3bbS5k7YS5l1dyIYYSziaoUqpYGtWqBPMyG9Z5x w2uMY64Z1sBZyKPkehlJtQgxWB/l18cXgUs9eNHC1zLVJxPOtTOqM631+fogcQblJ0X8YtzJDwS JIDTsSptcNFOcrWIbzTLz6umO/iFP1JhL4bMNvCPbTO86EUTs4XFS8Fp7HwyeIbPG1q+93Q3Jim IKG9d1c+yRc/Drzs3 X-Google-Smtp-Source: AGHT+IFkKP0/bxjxUSaylRZNBFb2jmXliX/Cc8L9pI2bxgyUjZXPUeSrW8ZKF4kKZJ2HOh4R2sl9mA== X-Received: by 2002:a05:6512:686:b0:553:24b7:2f6f with SMTP id 2adb3069b0e04-558fa91d29fmr771112e87.51.1752060022689; Wed, 09 Jul 2025 04:20:22 -0700 (PDT) Received: from pc636 (host-90-233-203-201.mobileonline.telia.com. [90.233.203.201]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-558fdb6a30esm67803e87.179.2025.07.09.04.20.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Jul 2025 04:20:21 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 9 Jul 2025 13:20:20 +0200 To: Michal Hocko Cc: Uladzislau Rezki , 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-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: F3D14C000B X-Stat-Signature: s1px5bphy6ad35s45oey5hz44akekjqt X-HE-Tag: 1752060024-743307 X-HE-Meta: U2FsdGVkX19jtVHT+oijrrRsYNrl5P011g6mQygT50JqA/Wz8y68bNLVl2hVi8pXQ5kAuNG1IPgZFZ15BhzLYhaEnYJxlv7+Il4Clb/cj5bSc32IXH0Yjj79GcZJAGRUCl7eoRQl3vTXvRj7Hm/Nv2HqUPzPATgH5CwEhh3nXUF535pjp1IZQ/1Vo4wu7zASjLpI3K2zaANTaW6qM+GrkQYWzpAupO6V/kpStKV7VQW7BZba1iNngmFHpvBnxNghoUnCp01LtjDRR7G8TtHDBarPGfNxOTTEMHF7n1ahcI84GgA4jzlYgKM5qY6y/42DNkulq+FUcV/mBo8jPKpBTXKKjHOGrS1BcZC1zbHk7mombXDS8jEAnps93IhKnoRkf+/UvIbiBCz1EqlmEqf1yWy+f8y3JSs66x6IXhjtgiCdvBRKNx1W7IPEZvkHGvAtPaMeOsD5WfWAVyJj98nyhQGQCwzcDSekslUAlpR9sARsVuGtMIcSjRKgtt1db5TCgmWgu6Ae30D7JyPas82QIl5XAwf7Fnr5Cee7t6qUf5BDhmsWs8hlz4XdQyh2N+Pcsr9ooHNIAAMJ82jpEWI8YoBi6RT4jOfR9pCVNetfRlybWLSSFGPvDp7oerP5uXmxgS9VPIScixH+urv+i1VBsdcs+02Iiyl3XiWKj1GtH/H6RbDoTGEIgY050mAm1ebhigsm4pIqiNR0DxGm20ZA5nrNdAmtcX42FdBS3kf1wsIERihmkWh1bfwPzBXKNVpEQi3AS3eTRwXw+VfcvAUXe1cfOg6mvkNtsMmxUKAntszmTFmB1mkx8a7TgRiqcP+nCoRb7f/90Y0XmQVO1MCk0nnv869b4426CcbG0CV3QzQzITAKbUncopHv6h8vyMOw8+FAPbf2aV1JreZW7Q4Fv8zUlTp6cQXGU7r82TJpQ0/h3xxbOFCTmTZ3BYeRQU1CJQxOgSdTC1PabbI6OLP UDWw+z7M uj2+W/Y1B0pMtCyOIaE865HdmP5vgO1/LxjT9WiqvqHyHad1Vk6w3wVmBJn5z+CG0DJU9PuJ9N5b8vPtVVN3pPO7rcwPEbsY1k9DpG46qaRjIG0618eJHMCAaHbzM0CySq93Tb8Kjo3bVNH0PDqHk3NF/2KEr2oOgARAH5yFpepwsKkE6ypC1CkIO7olRUvvad4XVjOZFPE117uY2JgtDA+DSgKDpCcX8IxEgtNhB8d8Ykstmx5qoWwNeWtWLMPZpWi6kWO3M3i+VgjlaE/rLkiRw+3I9I2P9/zPsgswWzL/GwWINhxT5vZukHbfCKCGyaQvkhRRewHGSN+PYbRD4jQQe666NwwFCeTHqMXgg+AWiixVdnYAobFJmG0s9D5l4Cu6m4No1Q1kxPvHi5TZNLSMmgTzAQ4iVkUeuIZhIVZ5ycZE8hlym0LjBrH3Tsf5m83faKiR7MKrHmL/axdONqtR5q9T8QhGptFqO 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 Tue, Jul 08, 2025 at 05:22:52PM +0200, Michal Hocko wrote: > On Tue 08-07-25 14:27:57, Uladzislau Rezki wrote: > > 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. > > You are right, I have misread the patch. I thought this includes > vm_area_alloc_pages as well but you are right this is only for page > tables and that seems much more reasonable. Having that outlined in the > changelog would have helped ;) > I will update the commit message in more detail in my next version. Thank you for! -- Uladzislau Rezki