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.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 4F5BBC3A5A1 for ; Mon, 26 Aug 2019 02:29:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1CDBB2070B for ; Mon, 26 Aug 2019 02:29:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CDBB2070B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9596F6B0518; Sun, 25 Aug 2019 22:29:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 90AA66B0519; Sun, 25 Aug 2019 22:29:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 820386B051A; Sun, 25 Aug 2019 22:29:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0075.hostedemail.com [216.40.44.75]) by kanga.kvack.org (Postfix) with ESMTP id 6483A6B0518 for ; Sun, 25 Aug 2019 22:29:46 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 1F7AB180AD7C1 for ; Mon, 26 Aug 2019 02:29:46 +0000 (UTC) X-FDA: 75862998372.25.cent94_54ee38da8f34c X-HE-Tag: cent94_54ee38da8f34c X-Filterd-Recvd-Size: 4760 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Mon, 26 Aug 2019 02:29:43 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 77760344; Sun, 25 Aug 2019 19:29:42 -0700 (PDT) Received: from [10.162.43.136] (p8cg001049571a15.blr.arm.com [10.162.43.136]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8EB213F718; Sun, 25 Aug 2019 19:29:32 -0700 (PDT) Subject: Re: [RFC V2 0/1] mm/debug: Add tests for architecture exported page table helpers To: Mark Rutland , Matthew Wilcox Cc: linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Greg Kroah-Hartman , Thomas Gleixner , Mike Rapoport , Jason Gunthorpe , Dan Williams , Peter Zijlstra , Michal Hocko , Mark Brown , Steven Price , Ard Biesheuvel , Masahiro Yamada , Kees Cook , Tetsuo Handa , Sri Krishna chowdary , Dave Hansen , Russell King - ARM Linux , Michael Ellerman , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , "David S. Miller" , Vineet Gupta , James Hogan , Paul Burton , Ralf Baechle , linux-snps-arc@lists.infradead.org, linux-mips@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org References: <1565335998-22553-1-git-send-email-anshuman.khandual@arm.com> <20190809101632.GM5482@bombadil.infradead.org> <20190809114450.GF48423@lakrids.cambridge.arm.com> From: Anshuman Khandual Message-ID: <652ae041-2033-1cf8-e559-6dcf85dd2fdd@arm.com> Date: Mon, 26 Aug 2019 07:59:36 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190809114450.GF48423@lakrids.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 08/09/2019 05:14 PM, Mark Rutland wrote: > On Fri, Aug 09, 2019 at 03:16:33AM -0700, Matthew Wilcox wrote: >> On Fri, Aug 09, 2019 at 01:03:17PM +0530, Anshuman Khandual wrote: >>> Should alloc_gigantic_page() be made available as an interface for general >>> use in the kernel. The test module here uses very similar implementation from >>> HugeTLB to allocate a PUD aligned memory block. Similar for mm_alloc() which >>> needs to be exported through a header. >> >> Why are you allocating memory at all instead of just using some >> known-to-exist PFNs like I suggested? > > IIUC the issue is that there aren't necessarily known-to-exist PFNs that > are sufficiently aligned -- they may not even exist. > > For example, with 64K pages, a PMD covers 512M. The kernel image is > (generally) smaller than 512M, and will be mapped at page granularity. > In that case, any PMD entry for a kernel symbol address will point to > the PTE level table, and that will only necessarily be page-aligned, as > any P?D level table is only necessarily page-aligned. Right. > > In the same configuration, you could have less than 512M of total > memory, and none of this memory is necessarily aligned to 512M. So > beyond the PTE level, I don't think you can guarantee a known-to-exist > valid PFN. Right a PMD aligned valid PFN might not even exist. This proposed patch which attempts to allocate memory chunk with required alignment will just fail indicating that such a valid PFN does not exist and hence will skip any relevant tests. At present this is done for PUD aligned allocation failure but we can similarly skip PMD relevant tests as well if PMD aligned memory chunk is not allocated. > > I also believe that synthetic PFNs could fail pfn_valid(), so that might > cause us pain too... Agreed. So do we have an agreement that it is better to use allocated memory with required alignment for the tests than known-to-exist PFNs ? - Anshuman