linux-parisc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Helge Deller <deller@gmx.de>
Cc: James Bottomley <James.Bottomley@hansenpartnership.com>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Parisc List <linux-parisc@vger.kernel.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
	linux-nvdimm@lists.01.org
Subject: Re: PATCH] fs/dax: fix compile problem on parisc and mips
Date: Fri, 4 Dec 2020 12:44:02 +0000	[thread overview]
Message-ID: <20201204124402.GN11935@casper.infradead.org> (raw)
In-Reply-To: <0f0ac7be-0108-0648-a4db-2f37db1c8114@gmx.de>

On Fri, Dec 04, 2020 at 08:57:37AM +0100, Helge Deller wrote:
> On 12/4/20 4:48 AM, Matthew Wilcox wrote:
> > On Thu, Dec 03, 2020 at 04:33:10PM -0800, James Bottomley wrote:
> >> These platforms define PMD_ORDER in asm/pgtable.h
> >
> > I think that's the real problem, though.
> >
> > #define PGD_ORDER       1 /* Number of pages per pgd */
> > #define PMD_ORDER       1 /* Number of pages per pmd */
> > #define PGD_ALLOC_ORDER (2 + 1) /* first pgd contains pmd */
> > #else
> > #define PGD_ORDER       1 /* Number of pages per pgd */
> > #define PGD_ALLOC_ORDER (PGD_ORDER + 1)
> >
> > That should clearly be PMD_ALLOC_ORDER, not PMD_ORDER.  Or even
> > PAGES_PER_PMD like the comment calls it, because I really think
> > that doing an order-3 (8 pages) allocation for the PGD is wrong.
> 
> We need a spinlock to protect parallel accesses to the PGD,
> search for pgd_spinlock().
> This spinlock is stored behind the memory used for the PGD, which
> is why we allocate more memory (and waste 3 pages).

There are better places to store it than that!  For example, storing it
in the struct page, like many architectures do for split ptlocks.
You'll have to skip the _pt_pad_1 so it doesn't get confused with
being a compound_head, but soemthing like this:

		struct {	/* PA-RISC PGD */
			unsigned long _pa_pad_1;	/* compound_head */
#if ALLOC_SPLIT_PA_PTLOCKS
			spinlock_t *pa_ptl;
#else
			spinlock_t pa_ptl;
#endif
		};

inside struct page (linux/mm_types.h) should do the trick.  You'll
still need to allocate them separately if various debugging options
are enabled (see the ALLOC_SPLIT_PTLOCKS for details), but usually
this will save you a lot of memory.

You could also fill in pt_mm like x86 does for its pgds, and then use
mm->page_table_lock to protect whatever the PGD lock currently protects.
Maybe page_table_lock is sometimes held when calling ptep_set_wrprotect()
and sometimes isn't; then this wouldn't work.

Also, could you fix the comments?  They don't match the code:

 #define PGD_ORDER      1 /* Number of pages per pgd */

should be

 #define PGD_ALLOC_ORDER      1 /* 2 pages (8KiB) per pgd */


  reply	other threads:[~2020-12-04 12:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04  0:33 PATCH] fs/dax: fix compile problem on parisc and mips James Bottomley
2020-12-04  3:48 ` Matthew Wilcox
2020-12-04  7:57   ` Helge Deller
2020-12-04 12:44     ` Matthew Wilcox [this message]
2020-12-04 13:28       ` John David Anglin
2020-12-04 14:11         ` Matthew Wilcox

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=20201204124402.GN11935@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=deller@gmx.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-parisc@vger.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).