linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arch@vger.kernel.org, x86@kernel.org, riel@redhat.com,
	Madhavan Srinivasan <maddy@linux.vnet.ibm.com>,
	dave.hansen@intel.com, peterz@infradead.org,
	Rusty Russell <rusty@rustcorp.com.au>,
	Hugh Dickins <hughd@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	ak@linux.intel.com, paulus@samba.org, mgorman@suse.de,
	linuxppc-dev@lists.ozlabs.org, mingo@kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc
Date: Fri, 23 May 2014 15:28:54 +0300 (EEST)	[thread overview]
Message-ID: <20140523122854.BDB36E009B@blue.fi.intel.com> (raw)
In-Reply-To: <20140521133408.4d2f1a551e9652fb0e12265f@linux-foundation.org>

Andrew Morton wrote:
> On Wed, 21 May 2014 16:40:27 +0300 (EEST) "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> wrote:
> 
> > > Or something.  Can we please get some code commentary over
> > > do_fault_around() describing this design decision and explaining the
> > > reasoning behind it?
> > 
> > I'll do this. But if do_fault_around() rework is needed, I want to do that
> > first.
> 
> This sort of thing should be at least partially driven by observation
> and I don't have the data for that.  My seat of the pants feel is that
> after the first fault, accesses at higher addresses are more
> common/probable than accesses at lower addresses.

It's probably true for data, but the feature is mostly targeted to code pages
and situation is not that obvious to me with all jumps.

> But we don't need to do all that right now.  Let's get the current
> implementation wrapped up for 3.15: get the interface finalized (bytes,
> not pages!)

The patch above by thread is okay for that, right?

> and get the current design decisions appropriately documented.

Here it is. Based on patch to convert order->bytes.

From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date: Fri, 23 May 2014 15:16:47 +0300
Subject: [PATCH] mm: document do_fault_around() feature

Some clarification on how faultaround works.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 mm/memory.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/mm/memory.c b/mm/memory.c
index 252b319e8cdf..8d723b8d3c86 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3404,6 +3404,10 @@ void do_set_pte(struct vm_area_struct *vma, unsigned long address,
 
 static unsigned long fault_around_bytes = 65536;
 
+/*
+ * fault_around_pages() and fault_around_mask() round down fault_around_bytes
+ * to nearest page order. It's what do_fault_around() expects to see.
+ */
 static inline unsigned long fault_around_pages(void)
 {
 	return rounddown_pow_of_two(fault_around_bytes) / PAGE_SIZE;
@@ -3445,6 +3449,29 @@ static int __init fault_around_debugfs(void)
 late_initcall(fault_around_debugfs);
 #endif
 
+/*
+ * do_fault_around() tries to map few pages around the fault address. The hope
+ * is that the pages will be needed soon and this would lower the number of
+ * faults to handle.
+ *
+ * It uses vm_ops->map_pages() to map the pages, which skips the page if it's
+ * not ready to be mapped: not up-to-date, locked, etc.
+ *
+ * This function is called with the page table lock taken. In the split ptlock
+ * case the page table lock only protects only those entries which belong to
+ * page table corresponding to the fault address.
+ *
+ * This function don't cross the VMA boundaries in order to call map_pages()
+ * only once.
+ *
+ * fault_around_pages() defines how many pages we'll try to map.
+ * do_fault_around() expects it to be power of two and less or equal to
+ * PTRS_PER_PTE.
+ *
+ * The virtual address of the area that we map is naturally aligned to the
+ * fault_around_pages() (and therefore to page order). This way it's easier to
+ * guarantee that we don't cross the page table boundaries.
+ */
 static void do_fault_around(struct vm_area_struct *vma, unsigned long address,
 		pte_t *pte, pgoff_t pgoff, unsigned int flags)
 {
-- 
 Kirill A. Shutemov

  reply	other threads:[~2014-05-23 12:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08  9:28 [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc Madhavan Srinivasan
2014-05-08  9:28 ` [PATCH V4 1/2] mm: move FAULT_AROUND_ORDER to arch/ Madhavan Srinivasan
2014-05-08  9:28 ` [PATCH V4 2/2] powerpc/pseries: init fault_around_order for pseries Madhavan Srinivasan
2014-05-20  7:28   ` Andrew Morton
2014-05-20  8:03     ` Madhavan Srinivasan
2014-05-15  8:25 ` [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc Madhavan Srinivasan
2014-05-15 17:28   ` Hugh Dickins
2014-05-19  0:12     ` Rusty Russell
2014-05-19  3:05       ` Madhavan Srinivasan
2014-05-19 23:23         ` Hugh Dickins
2014-05-19 23:43           ` Andrew Morton
2014-05-20  0:44             ` Kirill A. Shutemov
2014-05-20  6:22               ` Rusty Russell
2014-05-20  7:32                 ` Andrew Morton
2014-05-20  7:53                   ` Madhavan Srinivasan
2014-05-20 10:27                 ` Kirill A. Shutemov
2014-05-20 19:59                   ` Andrew Morton
2014-05-21 13:40                     ` Kirill A. Shutemov
2014-05-21 20:34                       ` Andrew Morton
2014-05-23 12:28                         ` Kirill A. Shutemov [this message]
2014-05-27  6:24                   ` Madhavan Srinivasan
2014-05-27 10:21                     ` Kirill A. Shutemov
2014-05-27 10:44                       ` Madhavan Srinivasan
2014-05-20  1:14           ` Rusty Russell
2014-05-20  2:34             ` Hugh Dickins
2014-05-20  2:06           ` Madhavan Srinivasan

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=20140523122854.BDB36E009B@blue.fi.intel.com \
    --to=kirill.shutemov@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=hughd@google.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.vnet.ibm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@kernel.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --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).