All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Will Deacon <will@kernel.org>,
	Michael Schmitz <schmitzmic@gmail.com>,
	Greg Ungerer <gerg@linux-m68k.org>
Subject: Re: [PATCH -v2 08/10] m68k,mm: Extend table allocator for multiple sizes
Date: Fri, 7 Feb 2020 13:11:54 +0100	[thread overview]
Message-ID: <CAMuHMdW8hWpSsf31P0hC=b23GCx4oFwfaVYKQ1qrZfwFCPK5-Q@mail.gmail.com> (raw)
In-Reply-To: <20200207113417.GG14914@hirez.programming.kicks-ass.net>

Hoi Peter,

On Fri, Feb 7, 2020 at 12:34 PM Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, Feb 07, 2020 at 11:56:40AM +0100, Geert Uytterhoeven wrote:
> > On Fri, Jan 31, 2020 at 1:56 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > > In addition to the PGD/PMD table size (128*4) add a PTE table size
> > > (64*4) to the table allocator. This completely removes the pte-table
> > > overhead compared to the old code, even for dense tables.
> >
> > Thanks for your patch!
> >
> > > Notes:
> > >
> > >  - the allocator gained a list_empty() check to deal with there not
> > >    being any pages at all.
> > >
> > >  - the free mask is extended to cover more than the 8 bits required
> > >    for the (512 byte) PGD/PMD tables.
> >
> > Being an mm-illiterate, I don't understand the relation between the number
> > of bits and the size (see below).
>
> If the table translates 7 bits of the address, it will have 1<<7 entries.
>
> > >  - NR_PAGETABLE accounting is restored.
> > >
> > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> >
> > WARNING: Missing Signed-off-by: line by nominal patch author 'Peter
> > Zijlstra <peterz@infradead.org>'
> > (in all patches)
> >
> > I can fix that (the From?) up while applying.
>
> I'm not sure where that warning comes from, but if you feel it needs
> fixing, sure. I normally only add the (Intel) thing to the SoB. I've so
> far never had complaints about that.

Checkpatch doesn't like this.

> > > --- a/arch/m68k/mm/motorola.c
> > > +++ b/arch/m68k/mm/motorola.c
> > > @@ -72,24 +72,35 @@ void mmu_page_dtor(void *page)
> > >     arch/sparc/mm/srmmu.c ... */
> > >
> > >  typedef struct list_head ptable_desc;
> > > -static LIST_HEAD(ptable_list);
> > > +
> > > +static struct list_head ptable_list[2] = {
> > > +       LIST_HEAD_INIT(ptable_list[0]),
> > > +       LIST_HEAD_INIT(ptable_list[1]),
> > > +};
> > >
> > >  #define PD_PTABLE(page) ((ptable_desc *)&(virt_to_page(page)->lru))
> > >  #define PD_PAGE(ptable) (list_entry(ptable, struct page, lru))
> > > -#define PD_MARKBITS(dp) (*(unsigned char *)&PD_PAGE(dp)->index)
> > > +#define PD_MARKBITS(dp) (*(unsigned int *)&PD_PAGE(dp)->index)
> > > +
> > > +static const int ptable_shift[2] = {
> > > +       7+2, /* PGD, PMD */
> > > +       6+2, /* PTE */
> > > +};
> > >
> > > -#define PTABLE_SIZE (PTRS_PER_PMD * sizeof(pmd_t))
> > > +#define ptable_size(type) (1U << ptable_shift[type])
> > > +#define ptable_mask(type) ((1U << (PAGE_SIZE / ptable_size(type))) - 1)
> >
> > So this is 0xff for PGD and PMD, like before, and 0xffff for PTE.
> > Why the latter value?
>
> The PGD/PMD being 7 bits are sizeof(unsigned long) << 7, or 512 bytes
> big. In one 4k page, there fit 8 such entries. 0xFF is 8 bits set, one
> for each of the 8 512 byte fragments.
>
> For the PTE tables, which are 6 bit and of sizeof(unsigned long) << 6,
> or 256 bytes, we can fit 16 in one 4k page, resulting in 0xFFFF.

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2020-02-07 12:12 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 12:45 [PATCH -v2 00/10] Rewrite Motorola MMU page-table layout Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 01/10] m68k,mm: Remove stray nocache in ColdFire pgalloc Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 02/10] m68k,mm: Fix ColdFire pgd_alloc() Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 03/10] m68k,mm: Unify Motorola MMU page setup Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 04/10] m68k,mm: Move the pointer table allocator to motorola.c Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 05/10] m68k,mm: Restructure Motorola MMU page-table layout Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 06/10] m68k,mm: Improve kernel_page_table() Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 07/10] m68k,mm: Use table allocator for pgtables Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 08/10] m68k,mm: Extend table allocator for multiple sizes Peter Zijlstra
2020-02-07 10:56   ` Geert Uytterhoeven
2020-02-07 11:34     ` Peter Zijlstra
2020-02-07 12:11       ` Geert Uytterhoeven [this message]
2020-02-07 12:30         ` Checkpatch being daft, Was: " Peter Zijlstra
2020-02-07 12:33           ` Peter Zijlstra
2020-02-09 18:24             ` Joe Perches
2020-02-10 16:38               ` Peter Zijlstra
2020-02-10 17:12                 ` Joe Perches
2020-02-10 18:52             ` [PATCH] checkpatch: Remove email address comment from email address comparisons Joe Perches
2020-02-10 22:25               ` Andrew Morton
2020-02-10 23:08                 ` Joe Perches
2020-02-07 12:57           ` Checkpatch being daft, Was: [PATCH -v2 08/10] m68k,mm: Extend table allocator for multiple sizes Joe Perches
2020-01-31 12:45 ` [PATCH -v2 09/10] m68k,mm: Fully initialize the page-table allocator Peter Zijlstra
2020-02-07 10:58   ` Geert Uytterhoeven
2020-02-07 11:37     ` Peter Zijlstra
2020-01-31 12:45 ` [PATCH -v2 10/10] m68k,mm: Change ColdFire pgtable_t Peter Zijlstra
2020-01-31 13:19 ` [PATCH -v2 00/10] Rewrite Motorola MMU page-table layout Greg Ungerer
2020-02-03  1:20   ` Greg Ungerer
2020-02-01  8:07 ` Michael Schmitz
2020-02-03  9:50 ` Will Deacon
2020-02-10 11:16 ` Geert Uytterhoeven
2020-03-09 10:15   ` Geert Uytterhoeven
2020-03-09 11:46     ` Peter Zijlstra

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='CAMuHMdW8hWpSsf31P0hC=b23GCx4oFwfaVYKQ1qrZfwFCPK5-Q@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=peterz@infradead.org \
    --cc=schmitzmic@gmail.com \
    --cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.