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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 918F5C3A5A1 for ; Mon, 26 Aug 2019 02:30:00 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6326F2070B for ; Mon, 26 Aug 2019 02:30:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="tchKQXy2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6326F2070B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=uPxO33VFzFs+ASPGZ+eP7h367I/F8147BccZzYV7KZY=; b=tchKQXy2qm6XJg Hj7ykCtNZYbEpkVGzNcPKGolMu1b/iSry/OpSHX7CTbpq3TbeF1LLpIFUdHpBac48aZHh7T+Zh4JB qBAiKB5S1SjTyc++0QO4tYfK10ryRa7chAmaWW5FXhiZ70upkscvTs1Uz4Bgag0U6Nody3qx+c2D5 ueF9eOE1gkqk1HulttcyDwQ7QqfqYsXr/a8+bPiZ5BhXiMOSP4QznZVvLjkgyQnn2STJYOrXBw4cF LF4iNhPpLhtYkdJuDvdVU3/6V5yxdTRMT6EoCSUxld+DYq3cidcVay/S7LVxD719SP/cm5RSagg2W +FHY97BzVNwRZZq+Nbxg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i24lS-00031T-Ts; Mon, 26 Aug 2019 02:29:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1i24lP-00030B-Jt; Mon, 26 Aug 2019 02:29:48 +0000 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 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-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190825_192947_745371_7ECE0A23 X-CRM114-Status: GOOD ( 18.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Tetsuo Handa , James Hogan , Heiko Carstens , Michal Hocko , linux-mm@kvack.org, Dave Hansen , Paul Mackerras , sparclinux@vger.kernel.org, Thomas Gleixner , linux-s390@vger.kernel.org, Michael Ellerman , x86@kernel.org, Russell King - ARM Linux , Steven Price , Jason Gunthorpe , linux-arm-kernel@lists.infradead.org, linux-snps-arc@lists.infradead.org, Kees Cook , Masahiro Yamada , Mark Brown , Dan Williams , Vlastimil Babka , Sri Krishna chowdary , Ard Biesheuvel , Greg Kroah-Hartman , linux-mips@vger.kernel.org, Ralf Baechle , linux-kernel@vger.kernel.org, Peter Zijlstra , Mike Rapoport , Paul Burton , Vineet Gupta , Martin Schwidefsky , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel