From: Andi Kleen <andi@firstfloor.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Shaohua Li <shaohua.li@intel.com>, linux-mm <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <andi@firstfloor.org>,
"Wu, Fengguang" <fengguang.wu@intel.com>
Subject: Re: [RFC]mm: batch activate_page() to reduce lock contention
Date: Fri, 23 Jul 2010 17:25:52 +0200 [thread overview]
Message-ID: <20100723152552.GE8127@basil.fritz.box> (raw)
In-Reply-To: <20100723234938.88EB.A69D9226@jp.fujitsu.com>
On Sat, Jul 24, 2010 at 12:10:49AM +0900, KOSAKI Motohiro wrote:
> > The zone->lru_lock is heavily contented in workload where activate_page()
> > is frequently used. We could do batch activate_page() to reduce the lock
> > contention. The batched pages will be added into zone list when the pool
> > is full or page reclaim is trying to drain them.
> >
> > 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.
-Andi
--
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>
next prev parent reply other threads:[~2010-07-23 15:25 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 [this message]
2010-07-23 18:06 ` KOSAKI Motohiro
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=20100723152552.GE8127@basil.fritz.box \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=kosaki.motohiro@jp.fujitsu.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.