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 CFB5EC433EF for ; Fri, 22 Apr 2022 03:08:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E7AF6B0072; Thu, 21 Apr 2022 23:08:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 395BF6B0073; Thu, 21 Apr 2022 23:08:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25E116B0074; Thu, 21 Apr 2022 23:08:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id 17D306B0072 for ; Thu, 21 Apr 2022 23:08:11 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D344123C65 for ; Fri, 22 Apr 2022 03:08:10 +0000 (UTC) X-FDA: 79383031140.18.0B2A25B Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by imf08.hostedemail.com (Postfix) with ESMTP id 7B0C316001C for ; Fri, 22 Apr 2022 03:08:07 +0000 (UTC) Received: by mail-pf1-f182.google.com with SMTP id w16so300852pfj.2 for ; Thu, 21 Apr 2022 20:08:10 -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=m+1GIKGybOnQbLN7cTlm8oMOflp0sBv16OQu4gOE9/A=; b=HhLHzeyKk42cFKoOn7VUEL+GOFJ4MyDXeKtwA7YC7n93roXgDOD0HxWBwDIgBFfGIp Ol46OR12jbghpPJakhFT3gfgC3XdhnlinzyFzJhfv3IojCZajPnNT0rLzAurjv1uLve1 IPgHB096FxAJPhITRnl7pp+WRXnu/xsd4J3wGzLWpyFUgd8vMZLOmDJZL8YkIQapeOFG bmXAOUE7nX0l+FSReIRqXLTo1KjVQORz4s5U6uaRL7QU3iSnq4AQlV2FlfkmJe03bWal 83zKi0tPeia3eOXtXjAQulaXl8puWqi/mfwwG9nzMLzYRbFM3t6NNIzxaTWF1BhjOAtL xcbg== 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=m+1GIKGybOnQbLN7cTlm8oMOflp0sBv16OQu4gOE9/A=; b=vxonibnFnil5iAOm+uB82hN135d4JNduTB5qcaR1XS8MEYqUX8JLvKCY2c17bJTP7Z 0P8ltvFQtsILz9JHJXPYGAXO7L1HvpPVfkH9jInzsWNcFTbiyR3LKbQwC0l0ru79OEHd joEbc/irEGiNlmNMffFAN5NB/40U7PoMDzi+K7nkst9ww7IM5/Dl55JsUEYUsNolJ4i8 f24BvKk9cLUBHl9W7NTaO/iGIXi3LKyN+i3VWrz3WHtsmDGB0smpLR+eew5nnpuOnOeT jLMqOUtuzYKF/y+Hc7DJhxkZhB0N/R2ci8rKUmDNIdN5wGAQw6x8yYXMq2MZPBpBZZIX CY7w== X-Gm-Message-State: AOAM5307JjCNdLueRfpRyhmpWK7stWoKlVQLPLbQMXoxYbHUaJkvSYB1 fPw23juQ2gQBsGK1K7Ijp80= X-Google-Smtp-Source: ABdhPJymAPQnihsodA6Yo6u41bnrJj6QjIfanBQZi3kmHKziRMS4Dfda7m/OupZYvSfD+U5q7NjunQ== X-Received: by 2002:a63:135a:0:b0:3aa:2cf6:ffd7 with SMTP id 26-20020a63135a000000b003aa2cf6ffd7mr2100607pgt.351.1650596889254; Thu, 21 Apr 2022 20:08:09 -0700 (PDT) Received: from localhost (193-116-116-20.tpgi.com.au. [193.116.116.20]) by smtp.gmail.com with ESMTPSA id z6-20020a056a00240600b004e17ab23340sm541646pfh.177.2022.04.21.20.08.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Apr 2022 20:08:08 -0700 (PDT) Date: Fri, 22 Apr 2022 13:08:03 +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: <1650596505.bxrmjmgjur.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9qwg444f9jg9p93w9da1fh1skr3kfp7k X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HhLHzeyK; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of npiggin@gmail.com designates 209.85.210.182 as permitted sender) smtp.mailfrom=npiggin@gmail.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 7B0C316001C X-HE-Tag: 1650596887-163110 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. Yeah I got a bit excited there, but fairly sure that's the bug. I'll do a proper patch. > 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. >=20 > Besides fixing the bisected issue (hopefully), it also more cleanly > separates the mapping from the backing allocation logic. And then since > all the pages are 4k (from the page allocator perspective), it would be > easier to support non-huge page aligned sizes. i.e. not use up a whole > additional 2MB page if you only need 4k more of allocation size. Somewhat. I'm not sure about freeing pages back for general use when they have page tables pointing to them. That will be a whole different kettle of fish I suspect. Honestly I don't think fragmentation has proven to be that bad of a problem yet that we'd want to do something like that yet. But there are other reasons to decople them in general. Some ppc32 I think had a different page size that was not a huge page which it could use to map vmalloc memory, for example. In any case I have no objections to making that part of it more flexible. Thanks, Nick