All of lore.kernel.org
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: Shaohua Li <shaohua.li@intel.com>, linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Wu, Fengguang" <fengguang.wu@intel.com>
Subject: Re: [RFC]mm: batch activate_page() to reduce lock contention
Date: Sat, 24 Jul 2010 03:06:33 +0900	[thread overview]
Message-ID: <AANLkTin3EbBe_x2JpdaOyz7KsBb7ztW++1=w_4RrPyK3@mail.gmail.com> (raw)
In-Reply-To: <20100723152552.GE8127@basil.fritz.box>

>> > For example, in a 4 socket 64 CPU system, create a sparse file and 64 processes,
>> > processes shared map to the file. Each process read access the whole file and
>> > then exit. The process exit will do unmap_vmas() and cause a lot of
>> > activate_page() call. In such workload, we saw about 58% total time reduction
>> > with below patch.
>>
>> I'm not sure this. Why process exiting on your workload call unmap_vmas?
>
> Trick question?
>
> Getting rid of a mm on process exit requires unmapping the vmas.

Oops, I misparsed unmap_vmas() and unuse_vma(). thanks fix me.

Ho Hum, zap_pte_range() call mark_page_accessed(). it was introduced slightly
recent (below).

----------------------------------------------------------------------------------
commit bf3f3bc5e734706730c12a323f9b2068052aa1f0
Author: Nick Piggin <npiggin@suse.de>
Date:   Tue Jan 6 14:38:55 2009 -0800

    mm: don't mark_page_accessed in fault path
----------------------------------------------------------------------------------


So, I guess we can apply following small optimization.
the intention is, if the exiting process is last mapped one,
we don't need to refrect its pte_young() because it is good
sign that the page is never touched.

Of cource, this is offtopic. On Shaouhua's testcase, 64 processes
shared map to the file.

-------------------------------------------------------------------------------
diff --git a/mm/memory.c b/mm/memory.c
index 833952d..ebdfcb1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -951,7 +951,8 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
                                if (pte_dirty(ptent))
                                        set_page_dirty(page);
                                if (pte_young(ptent) &&
-                                   likely(!VM_SequentialReadHint(vma)))
+                                   (page_mapcount(page) != 1) &&
+                                   !VM_SequentialReadHint(vma))
                                        mark_page_accessed(page);
                                rss[MM_FILEPAGES]--;
-------------------------------------------------------------------------------

One more offtopic:
we need to move ClearPageReferenced() from mark_page_accessed()
to __activate_page() honorly. unuse_vma() case also need to clear
page-referenced bit. I think.


Anyway, I agree original patch concept is fine. Thanks a lot of productive
information!

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-07-23 18:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-20  7:18 [RFC]mm: batch activate_page() to reduce lock contention Shaohua Li
2010-07-21 16:06 ` Minchan Kim
2010-07-22  0:27   ` Shaohua Li
2010-07-22  1:08     ` Minchan Kim
2010-07-22  5:17       ` Shaohua Li
2010-07-22 12:28         ` Minchan Kim
2010-07-23  8:12         ` Wu Fengguang
2010-07-23  8:14           ` Wu Fengguang
2010-07-22 23:49 ` Andrew Morton
2010-07-23 15:10 ` KOSAKI Motohiro
2010-07-23 15:25   ` Andi Kleen
2010-07-23 18:06     ` KOSAKI Motohiro [this message]
2010-07-26  5:08   ` Shaohua Li
2010-08-05 21:07     ` Andrew Morton
2010-08-06  3:08       ` Shaohua Li
2010-08-25 20:03         ` Andrew Morton
2010-08-26  7:59           ` Shaohua Li
2010-08-26 21:30             ` Andrew Morton
2010-08-27  8:17               ` Shaohua Li
2010-09-03 21:12                 ` Andrew Morton

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='AANLkTin3EbBe_x2JpdaOyz7KsBb7ztW++1=w_4RrPyK3@mail.gmail.com' \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=fengguang.wu@intel.com \
    --cc=linux-mm@kvack.org \
    --cc=shaohua.li@intel.com \
    /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.