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 5BC8AC8303C for ; Tue, 8 Jul 2025 15:22:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F26E16B009B; Tue, 8 Jul 2025 11:22:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED7806B009C; Tue, 8 Jul 2025 11:22:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E149C6B009D; Tue, 8 Jul 2025 11:22:58 -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 CB5F56B009B for ; Tue, 8 Jul 2025 11:22:58 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 74B825A72A for ; Tue, 8 Jul 2025 15:22:58 +0000 (UTC) X-FDA: 83641465236.25.2C38049 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by imf04.hostedemail.com (Postfix) with ESMTP id 8989240018 for ; Tue, 8 Jul 2025 15:22:56 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ErWU1A3F; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751988176; 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=vDbUdQbHcS+u2uA1nZKwuAGbng6kfr+9iRKL/0FgyEw=; b=sP61ZfuMYR1WReeNXUHLQBSW3vmZ6U4ZDrtgekyHtTtHSyiXYUb3M8kEJ4LAUoXc1VAjkG T+ouOIjinfARk1AT4Vd6Q/W4TnmBbK2Yf124VyZHDFeODprRcrcubClIXOV+cSvLAdy1F/ yFdgvaC4SEcSe5EFeXsxzIoezaFW38Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751988176; a=rsa-sha256; cv=none; b=3Us9LwX+rHedOM5JwhZ7FzIophKquIAecSFX6s6rUW/289t1W1ueFU5QB9mrNl2vuXcH2k MXiiMf+fC+YgB/l2+rwrDPliuo0tsRUCNqzUyeFzrmLZRLzuO0uRge4VHbB9HeuV9fl5nc HW+SSclsn0R+XfpvWUxeRLsdmyfrMas= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=ErWU1A3F; spf=pass (imf04.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-453398e90e9so31975895e9.1 for ; Tue, 08 Jul 2025 08:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1751988175; x=1752592975; 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=vDbUdQbHcS+u2uA1nZKwuAGbng6kfr+9iRKL/0FgyEw=; b=ErWU1A3FbnycZDJnpREnBYpSdbRsKmEonI0N14fofprb3KqMOMArJrWB8y9QGarNlh qfxfSAn/TAiwJPvaknbc+8BDnCAFQN9lygLgtTXJ0Oa7BZH/ZOYyUfdbaqBoAw/PlFsx vGb7g5FCPVNXkCmWug5KH2WWAtWHqmR2xNZfQTgvkYH4wTYKV0BjJVu5YUaSGfjB4fSh /PbVcZlJ5f0F7dMywQavepu5zDWRmMjSTr1szR61vM7MedC7eiuDzrgPXaHDta1Nu0Jo GK37XNU/08PrXY7lR3qXrI/UFv5L+xAmdZyDMA4B2n5TkVU/FG559zhQnE1wg5p2QfN5 RzyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751988175; x=1752592975; 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=vDbUdQbHcS+u2uA1nZKwuAGbng6kfr+9iRKL/0FgyEw=; b=LDLw2dEvEJ5ZMEd5Hoa26YT5S9gjjbbyfiRevbih0ls975HMdopUaoOrgcq2u+0H+h uQT3k+5iDUKolBoS6ZLwpvyvDcJMAQGJNwr/6Q82Z+7JlC5zg4ySrGsdFFnzRxJnO4CA jUKEW+4qKBrJV9LnERMMhImUTiHVqgFenXCdkq+LfUggBYDpOdbquV9pyM0z0PTimtcO AivMDKb7sRKpFlhgEyqkIjas2FBQVHb1Kkgq+ihvi5CL7TcoM9Xqbh3c+Pqdil3sKkQS w54YATxd56yd3oPxXGnEACd4T7tpj58ZYdNhmvBAh4GSKla4RB07EiYTIlBlRFlwbSQY 4CFw== X-Gm-Message-State: AOJu0YzlX63OyRXXZ9bHAmOZyQVE4HQvHqXPcy0dqjVAl1AWpbjxiHWD etX+IJ+orJOm3yWaPpzW8RKZDHyscqmzLBHeyoXDIRYxVdtq2WNdJrAzinCP1M6aI6w= X-Gm-Gg: ASbGncs1VSrvpI/n+r8RtLGD2QFfIGD5WRpm6C78QVZNJrUuDyVOHwOvr8izQv9hnv3 e8qC1NTYeW/b67vlKn/rCm+PSHZ/QODyg+D0kL6ioJhRvFU3rbaXg5wUrHObAZZHmivBTXP6GTT 5iDJnEp83hHzoZ0WQmyNQc/FxeAUKjTzPHIbZy4pXPJv69Ynn5C/Bwj1Q2A3EEqy2+bTnmPPfNL DxUIgeEmAxITKjsZGYqU3szXLKguBeR9vPa612C24z9TC68l4gtedrjI6FSTiNhq/r6sSDQV50k PjmygK2Z+i7vsWw1CtlBcbyfpi5L8hDLUlWa+h2eiQtVkvIEfEful3dyVhm6XRPRss9r4Eb/VWY = X-Google-Smtp-Source: AGHT+IEgN2ptsswvGbcqQV5HZKzy/tIMBN87UV1FLzjZJTzsOrsTBqZu7eb19DKwYvD06MzflwcQEA== X-Received: by 2002:a05:600c:458f:b0:43b:ce36:7574 with SMTP id 5b1f17b1804b1-454c6db327bmr70525085e9.11.1751988175023; Tue, 08 Jul 2025 08:22:55 -0700 (PDT) Received: from localhost (109-81-17-167.rct.o2.cz. [109.81.17.167]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-454cd3d25e4sm25058845e9.26.2025.07.08.08.22.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Jul 2025 08:22:54 -0700 (PDT) Date: Tue, 8 Jul 2025 17:22:52 +0200 From: Michal Hocko To: Uladzislau Rezki Cc: 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: rspam08 X-Rspamd-Queue-Id: 8989240018 X-Stat-Signature: c53qfiuae7w6yaxrotc5i1nfhkn5u3xg X-HE-Tag: 1751988176-653270 X-HE-Meta: U2FsdGVkX19rtwV07H90JCO+/9ui+H35wdB/30LRd2tP9KbCcN+Um78FRtKVpR050dtR5WZtt+MFqnfs54RXCzI28azQFiTGdSllMVKKli0j9uDLLhenS3xNntPlZKqZVYseoJKpwSM0AR7TlOF3p6hQSeLwknoC1Y04+fL57+k1ijG8BgbrxYUN4Ex95RGp2qaEDkn4OwNP2KdoWvmAqvaUrneGlwbTyPluHKYhIzD3iXsRtqWJfOPFEZ/xwCtyRqoG6dJ0nyz88/+a86AVhRcfqfyyYASLD+QIX0L9J95S+hkKuLQg1ggHva1ij7g4Jj+OaR06oto6fF7Ysa7uhKFW2e1xh/MFxaQ59NZsfiOrEL1FAyM40i9WIGmkjjUWfojsjvGvwQfX495oLvleBgIhtBkTm9u/yaM8jQ/HSmSdGt8ZW6pjRkjcmh0TiYcLarn4dkdANx2b9T4yKK9WLhneqo5rSuKT2+SWccswokz/PF5Abp3125FK+zXrfDTYU90568e46dJxFLNeHENJJNx2HyVQdFwUPvMV5cGjFoZyNJ3VRB3Rv7NziSMMJN4ZNEBeoX1BFtqAf+aoPZ2h82ibiDlQrZV22Cd8ziNEDnmt+3/B+z79VdgQgXO9o8uy2RmICYVxu9XVwvvn2550oYOdUx54lU5kThEH3+PJlqpVZCpQkrlGwvGABfwdXezbK6eQ04NlJbU9znYA90pxzW4Fv5ZWq1RPMoNt7GYrsM8CYR1DMCkRAr1TyNYuoXkbzZgPJaYPZuCXmWh9hn0QbmKBMeMxyCW7N5WIazvqoCHkBRp+5cc6e76BQ+tcfGGTUhVTdk6FoRzwMtXPCEjI4s+nwpK3hfarTHwDGWSg6MY8u1bK+LPE3RntZyEEzILbutpUxL8Lz0EbDDmx3hlIQ3HfEmhOZcNkZLDdlFoZWXEdpZocKsbzyoH08ajQJgP8uakaky8C9CuY/OU4R+i Ilc+Wd+9 a8/i3sn5P1nEZZ0E4kSKk3rXt6DD7V+kfm731VzT2ltSB+zrhqr2weS1fei1mfUGpGer8LsUyfJnOLPJLEEo0C5iIdhSof5ldIBxTkze4XUceQJTbKVpVrUtraIq9mJnygpZHXvpCr+6F8/X0BsQhEBrfcmCSslrM3XqQXjMEFOGVY163JMMWY5WIR4G9widdo+IKYV1tlo8Jx/K+/MS3mJPA53Dpg43a386Aur/hlPPERHmGD02wPBRJPhqGyz8iQG5fQhNTtdGZnnUzN+6jEEStvxTG+jj8P2sfoa1OoUYN2curU5wOWRgDlXcPUZ88p6B8nlt7XErmMMSL3/Y7Jn/M2A/hLVoEACRvKrQocXmK4ds= 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 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 ;) -- Michal Hocko SUSE Labs