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.2 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 0379AC35248 for ; Tue, 28 Jan 2020 03:06:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C43C02173E for ; Tue, 28 Jan 2020 03:06:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C43C02173E 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 5835E6B0007; Mon, 27 Jan 2020 22:06:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 533BC6B0269; Mon, 27 Jan 2020 22:06:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 422416B026A; Mon, 27 Jan 2020 22:06:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id 2893A6B0007 for ; Mon, 27 Jan 2020 22:06:24 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id CCA0C8248047 for ; Tue, 28 Jan 2020 03:06:23 +0000 (UTC) X-FDA: 76425554646.08.moon07_71f20395c8912 X-HE-Tag: moon07_71f20395c8912 X-Filterd-Recvd-Size: 6853 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Jan 2020 03:06:22 +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 DEA3A30E; Mon, 27 Jan 2020 19:06:21 -0800 (PST) Received: from [10.163.1.151] (unknown [10.163.1.151]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A0623F68E; Mon, 27 Jan 2020 19:06:06 -0800 (PST) Subject: Re: [PATCH V12] mm/debug: Add tests validating architecture page table helpers To: Qian Cai 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 Rutland , Mark Brown , Steven Price , Ard Biesheuvel , Masahiro Yamada , Kees Cook , Tetsuo Handa , Matthew Wilcox , 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 , "Kirill A . Shutemov" , Gerald Schaefer , Christophe Leroy , Ingo Molnar , 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: <1580174873-18117-1-git-send-email-anshuman.khandual@arm.com> <14882A91-17DE-4ABD-ABF2-08E7CCEDF660@lca.pw> From: Anshuman Khandual Message-ID: <214c0d53-eb34-9b0c-2e4e-1aa005146331@arm.com> Date: Tue, 28 Jan 2020 08:36:03 +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: <14882A91-17DE-4ABD-ABF2-08E7CCEDF660@lca.pw> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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 01/28/2020 07:41 AM, Qian Cai wrote: >=20 >=20 >> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual wrote: >> >> This adds tests which will validate architecture page table helpers an= d >> other accessors in their compliance with expected generic MM semantics= . >> This will help various architectures in validating changes to existing >> page table helpers or addition of new ones. >> >> This test covers basic page table entry transformations including but = not >> limited to old, young, dirty, clean, write, write protect etc at vario= us >> level along with populating intermediate entries with next page table = page >> and validating them. >> >> Test page table pages are allocated from system memory with required s= ize >> and alignments. The mapped pfns at page table levels are derived from = a >> real pfn representing a valid kernel text symbol. This test gets calle= d >> right after page_alloc_init_late(). >> >> This gets build and run when CONFIG_DEBUG_VM_PGTABLE is selected along= with >> CONFIG_VM_DEBUG. Architectures willing to subscribe this test also nee= d to >> select CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE which for now is limited to x8= 6 and >> arm64. Going forward, other architectures too can enable this after fi= xing >> build or runtime problems (if any) with their page table helpers. Hello Qian, >=20 > What=E2=80=99s the value of this block of new code? It only supports x8= 6 and arm64 > which are supposed to be good now. We have been over the usefulness of this code many times before as the pa= tch is already in it's V12. Currently it is enabled on arm64, x86 (except PAE), = arc and ppc32. There are build time or runtime problems with other archs which pr= event enablement of this test (for the moment) but then the goal is to integrat= e all of them going forward. The test not only validates platform's adherence t= o the expected semantics from generic MM but also helps in keeping it that way = during code changes in future as well. > Did those tests ever find any regression or this is almost only useful = for new The test has already found problems with s390 page table helpers. > architectures which only happened once in a few years? Again, not only it validates what exist today but its also a tool to make sure that all platforms continue adhere to a common agreed upon semantics as reflected through the tests here. > The worry if not many people will use this config and code those that m= uch in Debug features or tests in the kernel are used when required. These are n= ever or should not be enabled by default. AFAICT this is true even for entire DEB= UG_VM packaged tests. Do you have any particular data or precedence to substant= iate the fact that this test will be used any less often than the other simila= r ones in the tree ? I can only speak for arm64 platform but the very idea for t= his test came from Catalin when we were trying to understand the semantics fo= r THP helpers while enabling THP migration without split. Apart from going over= the commit messages from the past, there were no other way to figure out how = any particular page table helper is suppose to change given page table entry.= This test tries to formalize those semantics. > the future because it is inefficient to find bugs, it will simply be ro= tten Could you be more specific here ? What parts of the test are inefficient = ? I am happy to improve upon the test. Do let me know you if you have suggest= ions. > like a few other debugging options out there we have in the mainline th= at will be a pain to remove later on. > Even though I am not agreeing to your assessment about the usefulness of = the test without any substantial data backing up the claims, the test case in itself is very much compartmentalized, staying clear from generic MM and debug_vm_pgtable() is only function executing the test which is getting called from kernel_init_freeable() path. - Anshuman