From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Minchan Kim <minchan.kim@gmail.com>, Mel Gorman <mel@csn.ul.ie>,
Johannes Weiner <jweiner@redhat.com>
Subject: Re: [PATCH 1/2] mm,mlock: drain pagevecs asynchronously
Date: Wed, 04 Jan 2012 18:33:12 -0500 [thread overview]
Message-ID: <4F04E1B8.10109@gmail.com> (raw)
In-Reply-To: <20120104140547.75d4dd55.akpm@linux-foundation.org>
(1/4/12 5:05 PM), Andrew Morton wrote:
> On Sun, 1 Jan 2012 02:30:24 -0500
> kosaki.motohiro@gmail.com wrote:
>
>> Because lru_add_drain_all() spent much time.
>
> Those LRU pagevecs are horrid things. They add high code and
> conceptual complexity, they add pointless uniprocessor overhead and the
> way in which they leave LRU pages floating around not on an LRU is
> rather maddening.
>
> So the best way to fix all of this as well as this problem we're
> observing is, I hope, to completely remove them.
>
> They've been in there for ~10 years and at the time they were quite
> beneficial in reducing lru_lock contention, hold times, acquisition
> frequency, etc.
>
> The approach to take here is to prepare the patches which eliminate
> lru_*_pvecs then identify the problems which occur as a result, via
> code inspection and runtime testing. Then fix those up.
>
> Many sites which take lru_lock are already batching the operation.
> It's a matter of hunting down those sites which take the lock
> once-per-page and, if they have high frequency, batch them up.
>
> Converting readahead to batch the locking will be pretty simple
> (read_pages(), mpage_readpages(), others). That will fix pagefaults
> too.
>
> rotate_reclaimable_page() can be batched by batching
> end_page_writeback(): a bio contains many pages already.
>
> deactivate_page() can be batched too - invalidate_mapping_pages() is
> already working on large chunks of pages.
>
> Those three cases are fairly simple - we just didn't try, because the
> lru_*_pvecs were there to do the work for us.
got it. so, let's wait hugh's "mm: take pagevecs off reclaim stack" next spin
and make the patches on top of it.
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
David Rientjes <rientjes@google.com>,
Minchan Kim <minchan.kim@gmail.com>, Mel Gorman <mel@csn.ul.ie>,
Johannes Weiner <jweiner@redhat.com>
Subject: Re: [PATCH 1/2] mm,mlock: drain pagevecs asynchronously
Date: Wed, 04 Jan 2012 18:33:12 -0500 [thread overview]
Message-ID: <4F04E1B8.10109@gmail.com> (raw)
In-Reply-To: <20120104140547.75d4dd55.akpm@linux-foundation.org>
(1/4/12 5:05 PM), Andrew Morton wrote:
> On Sun, 1 Jan 2012 02:30:24 -0500
> kosaki.motohiro@gmail.com wrote:
>
>> Because lru_add_drain_all() spent much time.
>
> Those LRU pagevecs are horrid things. They add high code and
> conceptual complexity, they add pointless uniprocessor overhead and the
> way in which they leave LRU pages floating around not on an LRU is
> rather maddening.
>
> So the best way to fix all of this as well as this problem we're
> observing is, I hope, to completely remove them.
>
> They've been in there for ~10 years and at the time they were quite
> beneficial in reducing lru_lock contention, hold times, acquisition
> frequency, etc.
>
> The approach to take here is to prepare the patches which eliminate
> lru_*_pvecs then identify the problems which occur as a result, via
> code inspection and runtime testing. Then fix those up.
>
> Many sites which take lru_lock are already batching the operation.
> It's a matter of hunting down those sites which take the lock
> once-per-page and, if they have high frequency, batch them up.
>
> Converting readahead to batch the locking will be pretty simple
> (read_pages(), mpage_readpages(), others). That will fix pagefaults
> too.
>
> rotate_reclaimable_page() can be batched by batching
> end_page_writeback(): a bio contains many pages already.
>
> deactivate_page() can be batched too - invalidate_mapping_pages() is
> already working on large chunks of pages.
>
> Those three cases are fairly simple - we just didn't try, because the
> lru_*_pvecs were there to do the work for us.
got it. so, let's wait hugh's "mm: take pagevecs off reclaim stack" next spin
and make the patches on top of it.
next prev parent reply other threads:[~2012-01-04 23:33 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-30 6:36 [PATCH] mm: do not drain pagevecs for mlock Tao Ma
2011-12-30 6:36 ` Tao Ma
2011-12-30 8:11 ` KOSAKI Motohiro
2011-12-30 8:11 ` KOSAKI Motohiro
2011-12-30 8:48 ` Tao Ma
2011-12-30 9:31 ` KOSAKI Motohiro
2011-12-30 9:31 ` KOSAKI Motohiro
2011-12-30 9:45 ` Tao Ma
2011-12-30 9:45 ` Tao Ma
2011-12-30 10:07 ` KOSAKI Motohiro
2011-12-30 10:07 ` KOSAKI Motohiro
2012-01-01 7:30 ` [PATCH 1/2] mm,mlock: drain pagevecs asynchronously kosaki.motohiro
2012-01-01 7:30 ` kosaki.motohiro
2012-01-04 1:17 ` Minchan Kim
2012-01-04 1:17 ` Minchan Kim
2012-01-04 2:38 ` KOSAKI Motohiro
2012-01-04 2:38 ` KOSAKI Motohiro
2012-01-10 8:53 ` Tao Ma
2012-01-10 8:53 ` Tao Ma
2012-01-04 2:56 ` Hugh Dickins
2012-01-04 2:56 ` Hugh Dickins
2012-01-04 22:05 ` Andrew Morton
2012-01-04 22:05 ` Andrew Morton
2012-01-04 23:33 ` KOSAKI Motohiro [this message]
2012-01-04 23:33 ` KOSAKI Motohiro
2012-01-05 0:19 ` Hugh Dickins
2012-01-05 0:19 ` Hugh Dickins
2012-01-01 7:30 ` [PATCH 2/2] sysvshm: SHM_LOCK use lru_add_drain_all_async() kosaki.motohiro
2012-01-01 7:30 ` kosaki.motohiro
2012-01-04 1:51 ` Hugh Dickins
2012-01-04 1:51 ` Hugh Dickins
2012-01-04 2:19 ` KOSAKI Motohiro
2012-01-04 2:19 ` KOSAKI Motohiro
2012-01-04 5:17 ` Hugh Dickins
2012-01-04 5:17 ` Hugh Dickins
2012-01-04 8:34 ` KOSAKI Motohiro
2012-01-04 8:34 ` KOSAKI Motohiro
2012-01-06 6:13 ` [PATCH] mm: do not drain pagevecs for mlock Tao Ma
2012-01-06 6:13 ` Tao Ma
2012-01-06 6:18 ` KOSAKI Motohiro
2012-01-06 6:18 ` KOSAKI Motohiro
2012-01-06 6:30 ` Tao Ma
2012-01-06 6:30 ` Tao Ma
2012-01-06 6:33 ` KOSAKI Motohiro
2012-01-06 6:33 ` KOSAKI Motohiro
2012-01-06 6:46 ` Tao Ma
2012-01-06 6:46 ` Tao Ma
2012-01-09 23:58 ` KOSAKI Motohiro
2012-01-09 23:58 ` KOSAKI Motohiro
2012-01-10 2:08 ` Tao Ma
2012-01-10 2:08 ` Tao Ma
2012-01-09 7:25 ` Tao Ma
2012-01-09 7:25 ` Tao Ma
2011-12-30 10:14 ` KOSAKI Motohiro
2011-12-30 10:14 ` KOSAKI Motohiro
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=4F04E1B8.10109@gmail.com \
--to=kosaki.motohiro@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jweiner@redhat.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=rientjes@google.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.