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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 65F5CC43462 for ; Fri, 16 Apr 2021 05:19:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C8DC56113D for ; Fri, 16 Apr 2021 05:19:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C8DC56113D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgroup.eu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 37CC06B0088; Fri, 16 Apr 2021 01:19:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 305BB6B0089; Fri, 16 Apr 2021 01:19:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 17F476B008A; Fri, 16 Apr 2021 01:19:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id E916A6B0088 for ; Fri, 16 Apr 2021 01:19:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A84DD1F1B for ; Fri, 16 Apr 2021 05:19:51 +0000 (UTC) X-FDA: 78037078182.14.828A2A4 Received: from pegase1.c-s.fr (pegase1.c-s.fr [93.17.236.30]) by imf16.hostedemail.com (Postfix) with ESMTP id 2861080192DA for ; Fri, 16 Apr 2021 05:19:50 +0000 (UTC) Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 4FM4K01LdRzB09bJ; Fri, 16 Apr 2021 07:19:48 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id n0Rd_tp0QaYj; Fri, 16 Apr 2021 07:19:48 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 4FM4Jz6gV6zB09b1; Fri, 16 Apr 2021 07:19:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id B55238B81C; Fri, 16 Apr 2021 07:19:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3r3x5D8gtbOn; Fri, 16 Apr 2021 07:19:48 +0200 (CEST) Received: from [192.168.4.90] (unknown [192.168.4.90]) by messagerie.si.c-s.fr (Postfix) with ESMTP id E3F818B81A; Fri, 16 Apr 2021 07:19:47 +0200 (CEST) Subject: Re: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage() To: Daniel Axtens , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Steven Price , akpm@linux-foundation.org Cc: linux-arch@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-riscv@lists.infradead.org, x86@kernel.org, linux-mm@kvack.org References: <1ef6b954fb7b0f4dfc78820f1e612d2166c13227.1618506910.git.christophe.leroy@csgroup.eu> <8735vr16sd.fsf@dja-thinkpad.axtens.net> From: Christophe Leroy Message-ID: Date: Fri, 16 Apr 2021 07:19:46 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <8735vr16sd.fsf@dja-thinkpad.axtens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 2861080192DA X-Stat-Signature: 4qew8erqwhj7381ikafzp1hiah175izh Received-SPF: none (csgroup.eu>: No applicable sender policy available) receiver=imf16; identity=mailfrom; envelope-from=""; helo=pegase1.c-s.fr; client-ip=93.17.236.30 X-HE-DKIM-Result: none/none X-HE-Tag: 1618550390-844429 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: Le 16/04/2021 =C3=A0 01:12, Daniel Axtens a =C3=A9crit=C2=A0: > Hi Christophe, >=20 >> static void note_page(struct ptdump_state *pt_st, unsigned long addr= , int level, >> - u64 val) >> + u64 val, unsigned long page_size) >=20 > Compilers can warn about unused parameters at -Wextra level. However, > reading scripts/Makefile.extrawarn it looks like the warning is > explicitly _disabled_ in the kernel at W=3D1 and not reenabled at W=3D2= or > W=3D3. So I guess this is fine... There are a lot lot lot functions having unused parameters in the kernel = , especially the ones that=20 are re-implemented by each architecture. >=20 >> @@ -126,7 +126,7 @@ static int ptdump_hole(unsigned long addr, unsigne= d long next, >> { >> struct ptdump_state *st =3D walk->private; >> =20 >> - st->note_page(st, addr, depth, 0); >> + st->note_page(st, addr, depth, 0, 0); >=20 > I know it doesn't matter at this point, but I'm not really thrilled by > the idea of passing 0 as the size here. Doesn't the hole have a known > page size? The hole has a size for sure, I don't think we can call it a page size: On powerpc 8xx, we have 4 page sizes: 8M, 512k, 16k and 4k. A page table will cover 4M areas and will contain pages of size 512k, 16k= and 4k. A PGD table contains either entries which points to a page table (coverin= g 4M), or two identical=20 consecutive entries pointing to the same hugepd which contains a single P= TE for an 8M page. So, if a PGD entry is empty, the hole is 4M, it corresponds to none of th= e page sizes the=20 architecture supports. But looking at what is done with that size, it can make sense to pass it = to notepage() anyway. Let's=20 do that. >=20 >> =20 >> return 0; >> } >> @@ -153,5 +153,5 @@ void ptdump_walk_pgd(struct ptdump_state *st, stru= ct mm_struct *mm, pgd_t *pgd) >> mmap_read_unlock(mm); >> =20 >> /* Flush out the last page */ >> - st->note_page(st, 0, -1, 0); >> + st->note_page(st, 0, -1, 0, 0); >=20 > I'm more OK with the idea of passing 0 as the size when the depth is -1 > (don't know): if we don't know the depth we conceptually can't know the > page size. >=20 > Regards, > Daniel >=20