linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Daniel Axtens <dja@axtens.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Steven Price <steven.price@arm.com>,
	akpm@linux-foundation.org
Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-riscv@lists.infradead.org, linuxppc-dev@lists.ozlabs.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 3/5] mm: ptdump: Provide page size to notepage()
Date: Fri, 16 Apr 2021 07:19:46 +0200	[thread overview]
Message-ID: <ce7773ea-80d0-14c8-3547-d53424682469@csgroup.eu> (raw)
In-Reply-To: <8735vr16sd.fsf@dja-thinkpad.axtens.net>



Le 16/04/2021 à 01:12, Daniel Axtens a écrit :
> Hi Christophe,
> 
>>   static void note_page(struct ptdump_state *pt_st, unsigned long addr, int level,
>> -		      u64 val)
>> +		      u64 val, unsigned long page_size)
> 
> 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=1 and not reenabled at W=2 or
> W=3. So I guess this is fine...

There are a lot lot lot functions having unused parameters in the kernel , especially the ones that 
are re-implemented by each architecture.

> 
>> @@ -126,7 +126,7 @@ static int ptdump_hole(unsigned long addr, unsigned long next,
>>   {
>>   	struct ptdump_state *st = walk->private;
>>   
>> -	st->note_page(st, addr, depth, 0);
>> +	st->note_page(st, addr, depth, 0, 0);
> 
> 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 (covering 4M), or two identical 
consecutive entries pointing to the same hugepd which contains a single PTE for an 8M page.

So, if a PGD entry is empty, the hole is 4M, it corresponds to none of the page sizes the 
architecture supports.


But looking at what is done with that size, it can make sense to pass it to notepage() anyway. Let's 
do that.

> 
>>   
>>   	return 0;
>>   }
>> @@ -153,5 +153,5 @@ void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm, pgd_t *pgd)
>>   	mmap_read_unlock(mm);
>>   
>>   	/* Flush out the last page */
>> -	st->note_page(st, 0, -1, 0);
>> +	st->note_page(st, 0, -1, 0, 0);
> 
> 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.
> 
> Regards,
> Daniel
> 

  reply	other threads:[~2021-04-16  5:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 17:18 [PATCH v1 0/5] Convert powerpc to GENERIC_PTDUMP Christophe Leroy
2021-04-15 17:18 ` [PATCH v1 1/5] mm: pagewalk: Fix walk for hugepage tables Christophe Leroy
2021-04-15 22:43   ` Daniel Axtens
2021-04-16  5:48     ` Christophe Leroy
2021-04-15 17:18 ` [PATCH v1 2/5] mm: ptdump: Fix build failure Christophe Leroy
2021-04-15 17:18 ` [PATCH v1 3/5] mm: ptdump: Provide page size to notepage() Christophe Leroy
2021-04-15 23:12   ` Daniel Axtens
2021-04-16  5:19     ` Christophe Leroy [this message]
2021-04-16  9:28   ` Steven Price
2021-04-16 10:38     ` Christophe Leroy
2021-04-16 10:51       ` Steven Price
2021-04-16 11:08         ` Christophe Leroy
2021-04-16 13:00           ` Steven Price
2021-04-16 14:40             ` Christophe Leroy
2021-04-16 15:04               ` Christophe Leroy
2021-04-16 15:15                 ` Christophe Leroy
2021-04-16 16:00                   ` Steven Price
2021-04-19 13:14         ` Christophe Leroy
2021-04-19 14:00           ` Steven Price
2021-04-19 16:41             ` Christophe Leroy
2021-04-15 17:18 ` [PATCH v1 4/5] mm: ptdump: Support hugepd table entries Christophe Leroy
2021-04-15 23:29   ` Daniel Axtens
2021-04-16  5:25     ` Christophe Leroy
2021-04-15 17:18 ` [PATCH v1 5/5] powerpc/mm: Convert powerpc to GENERIC_PTDUMP Christophe Leroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce7773ea-80d0-14c8-3547-d53424682469@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=akpm@linux-foundation.org \
    --cc=benh@kernel.crashing.org \
    --cc=dja@axtens.net \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=steven.price@arm.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).