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 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 23C2DECE58F for ; Tue, 15 Oct 2019 11:36:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E5E1921848 for ; Tue, 15 Oct 2019 11:36:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E5E1921848 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8E85E8E0006; Tue, 15 Oct 2019 07:36:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8BFD78E0001; Tue, 15 Oct 2019 07:36:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FD7C8E0006; Tue, 15 Oct 2019 07:36:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0232.hostedemail.com [216.40.44.232]) by kanga.kvack.org (Postfix) with ESMTP id 5F6CC8E0001 for ; Tue, 15 Oct 2019 07:36:12 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id 09B758024B3B for ; Tue, 15 Oct 2019 11:36:12 +0000 (UTC) X-FDA: 76045815384.27.fang62_361070528b217 X-HE-Tag: fang62_361070528b217 X-Filterd-Recvd-Size: 5181 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Tue, 15 Oct 2019 11:36:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 090FCAA35; Tue, 15 Oct 2019 11:36:09 +0000 (UTC) Date: Tue, 15 Oct 2019 13:36:06 +0200 From: Michal Hocko To: Matthew Wilcox Cc: Anshuman Khandual , akpm@linux-foundation.org, ard.biesheuvel@linaro.org, broonie@kernel.org, christophe.leroy@c-s.fr, dan.j.williams@intel.com, dave.hansen@intel.com, davem@davemloft.net, gerald.schaefer@de.ibm.com, gregkh@linuxfoundation.org, heiko.carstens@de.ibm.com, jgg@ziepe.ca, jhogan@kernel.org, keescook@chromium.org, kirill@shutemov.name, linux@armlinux.org.uk, mark.rutland@arm.com, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, mpe@ellerman.id.au, paul.burton@mips.com, paulus@samba.org, penguin-kernel@i-love.sakura.ne.jp, peterz@infradead.org, ralf@linux-mips.org, rppt@linux.vnet.ibm.com, schowdary@nvidia.com, schwidefsky@de.ibm.com, Steven.Price@arm.com, tglx@linutronix.de, vbabka@suse.cz, vgupta@synopsys.com, yamada.masahiro@socionext.com, linux-mm@kvack.org Subject: Re: + mm-hugetlb-make-alloc_gigantic_page-available-for-general-use.patch added to -mm tree Message-ID: <20191015113606.GA317@dhcp22.suse.cz> References: <20191011202932.GZoUOoURm%akpm@linux-foundation.org> <20191014121730.GE317@dhcp22.suse.cz> <20191014202926.GZ32665@bombadil.infradead.org> <0bcb05da-5775-99d8-46d9-3140b6e1dd63@arm.com> <20191015112433.GC32665@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191015112433.GC32665@bombadil.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) 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: On Tue 15-10-19 04:24:33, Matthew Wilcox wrote: > On Tue, Oct 15, 2019 at 03:00:49PM +0530, Anshuman Khandual wrote: > > On 10/15/2019 01:59 AM, Matthew Wilcox wrote: > > > On Mon, Oct 14, 2019 at 02:17:30PM +0200, Michal Hocko wrote: > > >> On Fri 11-10-19 13:29:32, Andrew Morton wrote: > > >>> alloc_gigantic_page() implements an allocation method where it scans over > > >>> various zones looking for a large contiguous memory block which could not > > >>> have been allocated through the buddy allocator. A subsequent patch which > > >>> tests arch page table helpers needs such a method to allocate PUD_SIZE > > >>> sized memory block. In the future such methods might have other use cases > > >>> as well. So alloc_gigantic_page() has been split carving out actual > > >>> memory allocation method and made available via new > > >>> alloc_gigantic_page_order(). > > >> > > >> You are exporting a helper used for hugetlb internally. Is this really > > >> what is needed? I haven't followed this patchset but don't you simply > > >> need a generic 1GB allocator? If yes then you should be looking at > > >> alloc_contig_range. > > > > > > He actually doesn't need to allocate any memory at all. All he needs is > > > the address of a valid contiguous PUD-sized chunk of memory. > > > > > > > We had already discussed about the benefits of allocated memory over > > synthetic pfn potentially derived from a kernel text symbol. More > > over we are not adding any new helper or new code for this purpose, > > but instead just trying to reuse code which is already present. > > Yes, and I'm pretty sure you're just wrong. But I don't know that you're > wrong for all architectures. Re-reading that, I'm still not sure you > understood what I was suggesting, so I'll say it again differently. > > Look up a kernel symbol, something like kernel_init(). This will > have a virtual address upon which it is safe to call virt_to_pfn(). > Let's presume it's in PFN 0x12345678. Use 0x12345678 as the PFN for > your PTE level tests. > > Then clear the bottom (eg) 9 bits from it and use 0x1234400 for your PMD > level tests. Then clear the bottom 18 bits from it and use 0x12300000 > for your PUD level tests. > > I don't think it matters whether there's physical memory at PFN 0x12300000 > or not. The various p?d_* functions should work as long as the PFN is > in some plausible range. > > I gave up arguing because you seemed uninterested in this approach, > but now that Michal is pointing out that your approach is all wrong, > maybe you'll listen. Just for the record. I didn't really get to read the patch 2 in this series. Matthew is right that I disagree with the current state of the "large pages" allocator. If my concerns get resolved then I do not mind having it regardless of what patch 2 ends up doing and whether it uses it or not. On the other hand, having a testing code that really requires a lot of memory to allocate to test page table walkers seems indeed a bit too strong of an assumption. Especially when there are ways around that as Matthew is suggesting so I would really listen to his suggestions. -- Michal Hocko SUSE Labs