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 8AAA9C433EF for ; Fri, 22 Apr 2022 03:33:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AA9E6B0072; Thu, 21 Apr 2022 23:33:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1324B6B0073; Thu, 21 Apr 2022 23:33:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9F8E6B0074; Thu, 21 Apr 2022 23:33:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id D31906B0072 for ; Thu, 21 Apr 2022 23:33:14 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9E8E823DE5 for ; Fri, 22 Apr 2022 03:33:14 +0000 (UTC) X-FDA: 79383094308.01.933B13E Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf22.hostedemail.com (Postfix) with ESMTP id A8540C0008 for ; Fri, 22 Apr 2022 03:33:13 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id b7so8036492plh.2 for ; Thu, 21 Apr 2022 20:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=iEvjNri7DPZ9ItG4XGZ9YPg2UHpVLKH81mxJqNaUcj0=; b=Aq60mgyBoX2mT/QLPnHbxI46zNvEmsTfo/Tli60lN72v6jC7DT0j3zONy0ZgiY7Qyl z8jdeaAq5R2gKC+ImMVe+c/PV+VSe8V7y0klC7p8JOpqhMjVl3QzxI3Feubga3nGaxKz qhMOU9APAVCNoGPnfIXjHNlZ17Q9blfL0l6sgwwZaVPqz8bz6R19e54+bbCV1mrNlEUD bjEvasU7pf2iHzVZuJ8byn3CnoX4Ik84oRFdyx6+HKAteKc43dL0StFBTOjL/9i39j5w zFwmn+iyDuV/occq8YhdWsFjsZh/8VRJxgoXtbp2qc6cHaGKl9rbI3eSX3iW70yhW52i oA9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=iEvjNri7DPZ9ItG4XGZ9YPg2UHpVLKH81mxJqNaUcj0=; b=OD7071MoMve2jsVE4Gqiy3yGuCt3uHtGkikHEIuuysVjIhPxt7umWBkq97OWwte7mf lsbHqxtJL1wacK25Pd5+JfMLaRPhg5A0b9onsHdFKTM1Y1OuK/cCj83wyhKkdC5yT0bh D/s3YERTutjJCnJjhxVEosBPb0Cn4uGD4/rqvgG9Qc38B3AO+4Iel4OnWYQXcfsy+5bU UWy949LTSTmjglScsGaJqkKuRaZcbSOxX+PHZDeACyd771mC7UV1i+D+IKNIaCHPoiu9 xkmwbKvIOcblzxTDvZmTzm4YWWHRUnhWIK7/pH8AsHhx7OxgnadbP/M+flIevh0fCIza YecA== X-Gm-Message-State: AOAM533pHMgxMcFdUOLNHMFawSI9LWNmfiwEe2MIHSpi7gykjQd9pC/3 DdHQjjWXv7qRoEmaD/XlB/I= X-Google-Smtp-Source: ABdhPJx7lRL9QK5ePoso16IgWMANaKMb/6OwG5jyhWsIxEKtOYH2BOzG7LiP9ICqEPaIN/Tr9+8Xng== X-Received: by 2002:a17:90b:2786:b0:1d5:bfa1:c7f4 with SMTP id pw6-20020a17090b278600b001d5bfa1c7f4mr3031548pjb.101.1650598392956; Thu, 21 Apr 2022 20:33:12 -0700 (PDT) Received: from localhost (193-116-116-20.tpgi.com.au. [193.116.116.20]) by smtp.gmail.com with ESMTPSA id f187-20020a6251c4000000b005058e59604csm562092pfb.217.2022.04.21.20.33.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 20:33:11 -0700 (PDT) Date: Fri, 22 Apr 2022 13:33:07 +1000 From: Nicholas Piggin Subject: Re: [PATCH v4 bpf 0/4] vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP To: "Edgecombe, Rick P" , "Torvalds, Linus" Cc: "akpm@linux-foundation.org" , "ast@kernel.org" , "bp@alien8.de" , "bpf@vger.kernel.org" , "daniel@iogearbox.net" , "dborkman@redhat.com" , "edumazet@google.com" , "hch@infradead.org" , "hpa@zytor.com" , "imbrenda@linux.ibm.com" , "Kernel-team@fb.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "mbenes@suse.cz" , "mcgrof@kernel.org" , "pmladek@suse.com" , "rppt@kernel.org" , "song@kernel.org" , "songliubraving@fb.com" References: <20220415164413.2727220-1-song@kernel.org> <4AD023F9-FBCE-4C7C-A049-9292491408AA@fb.com> <88eafc9220d134d72db9eb381114432e71903022.camel@intel.com> <1650511496.iys9nxdueb.astroid@bobo.none> <1650530694.evuxjgtju7.astroid@bobo.none> <25437eade8b2ecf52ff9666a7de9e36928b7d28f.camel@intel.com> <1650584815.0dtcbd4qky.astroid@bobo.none> <310d562b80ad328e19a4959356600e4efe49cf4c.camel@intel.com> In-Reply-To: <310d562b80ad328e19a4959356600e4efe49cf4c.camel@intel.com> MIME-Version: 1.0 Message-Id: <1650598153.250diijyao.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A8540C0008 X-Stat-Signature: 5qwbg3cuoncg8z1gnj98one4gtkx3d33 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Aq60mgyB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf22.hostedemail.com: domain of npiggin@gmail.com designates 209.85.214.175 as permitted sender) smtp.mailfrom=npiggin@gmail.com X-HE-Tag: 1650598393-112470 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: Excerpts from Edgecombe, Rick P's message of April 22, 2022 12:29 pm: > On Fri, 2022-04-22 at 10:12 +1000, Nicholas Piggin wrote: >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >> index e163372d3967..70933f4ed069 100644 >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -2925,12 +2925,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, >> if (nr !=3D nr_pages_request) >> break; >> } >> - } else >> - /* >> - * Compound pages required for remap_vmalloc_page if >> - * high-order pages. >> - */ >> - gfp |=3D __GFP_COMP; >> + } >> =20 >> /* High-order pages or fallback path if "bulk" fails. */ >> =20 >> @@ -2944,6 +2939,13 @@ vm_area_alloc_pages(gfp_t gfp, int nid, >> page =3D alloc_pages_node(nid, gfp, order); >> if (unlikely(!page)) >> break; >> + /* >> + * Higher order allocations must be able to be >> treated as >> + * indepdenent small pages by callers (as they can >> with >> + * small page allocs). >> + */ >> + if (order) >> + split_page(page, order); >> =20 >> /* >> * Careful, we allocate and map page-order pages, but >=20 > FWIW, I like this direction. I think it needs to free them differently > though? Since currently assumes they are high order pages in that path. > I also wonder if we wouldn't need vm_struct->page_order anymore, and > all the places that would percolates out to. Basically all the places > where it iterates through vm_struct->pages with page_order stepping. To respond to this, I do like having the huge page indicator in /proc/vmallocinfo. Which is really the only use of it. I might just keep it in for now. Thanks, Nick