From: Shaohua Li <shaohua.li@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"aarcange@redhat.com" <aarcange@redhat.com>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
mel <mel@csn.ul.ie>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch 5/5]thp: split huge page if head page is isolated
Date: Fri, 28 Oct 2011 16:25:56 +0800 [thread overview]
Message-ID: <1319790356.22361.165.camel@sli10-conroe> (raw)
In-Reply-To: <20111028073026.GB6268@barrios-laptop.redhat.com>
On Fri, 2011-10-28 at 15:30 +0800, Minchan Kim wrote:
> On Fri, Oct 28, 2011 at 01:11:55PM +0800, Shaohua Li wrote:
> > On Fri, 2011-10-28 at 07:34 +0800, Minchan Kim wrote:
> > > On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > > > With current logic, if page reclaim finds a huge page, it will just reclaim
> > > > the head page and leave tail pages reclaimed later. Let's take an example,
> > > > lru list has page A and B, page A is huge page:
> > > > 1. page A is isolated
> > > > 2. page B is isolated
> > > > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > > > page A+1, page A+2, ... are added to lru list.
> > > > 4. shrink_page_list() adds page B to swap page cache.
> > > > 5. page A and B is written out and reclaimed.
> > > > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > > > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> > >
> > > I don't see your code yet but have a question.
> > > You mitigate this problem by 4/5 which could add subpages into lru tail
> > > so subpages would reclaim next interation of reclaim.
> > >
> > > What do we need 5/5?
> > > Do I miss something?
> > Both patches are required. without this patch, current page reclaim will
> > only reclaim the first page of a huge page, because the hugepage isn't
> > split yet. The hugepage is split when the first page is being written to
> > swap, which is too later and page reclaim might already isolated a lot
> > of pages.
>
> When split happens, subpages would be located in tail of LRU by your 4/5.
> (Assume tail of LRU is old age).
yes, but a lot of other pages already isolated. we will reclaim those
pages first. for example, reclaim huge page A, B. current reclaim order
is A, B, A+1, ... B+1, because we will isolated A and B first, all tail
pages are not isolated yet. While with my patch, the order is A, A
+1, ... B, B+1,.... with my patch, we can avoid unnecessary page split
or page isolation. This is exactly why my patch reduces the thp_split
count.
> In addtion, isolation happens 32 page chunk so the subpages would be isolated
> and reclaimed in next iteration. I think 32 pages are not too many.
>
> What do you think about it?
since headpage and tailpages are in different list, the 32 chunk will
not include tailpages.
WARNING: multiple messages have this Message-ID (diff)
From: Shaohua Li <shaohua.li@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"aarcange@redhat.com" <aarcange@redhat.com>,
Hugh Dickins <hughd@google.com>, Rik van Riel <riel@redhat.com>,
mel <mel@csn.ul.ie>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [patch 5/5]thp: split huge page if head page is isolated
Date: Fri, 28 Oct 2011 16:25:56 +0800 [thread overview]
Message-ID: <1319790356.22361.165.camel@sli10-conroe> (raw)
In-Reply-To: <20111028073026.GB6268@barrios-laptop.redhat.com>
On Fri, 2011-10-28 at 15:30 +0800, Minchan Kim wrote:
> On Fri, Oct 28, 2011 at 01:11:55PM +0800, Shaohua Li wrote:
> > On Fri, 2011-10-28 at 07:34 +0800, Minchan Kim wrote:
> > > On Tue, Oct 25, 2011 at 10:59:40AM +0800, Shaohua Li wrote:
> > > > With current logic, if page reclaim finds a huge page, it will just reclaim
> > > > the head page and leave tail pages reclaimed later. Let's take an example,
> > > > lru list has page A and B, page A is huge page:
> > > > 1. page A is isolated
> > > > 2. page B is isolated
> > > > 3. shrink_page_list() adds page A to swap page cache. so page A is split.
> > > > page A+1, page A+2, ... are added to lru list.
> > > > 4. shrink_page_list() adds page B to swap page cache.
> > > > 5. page A and B is written out and reclaimed.
> > > > 6. page A+1, A+2 ... is isolated and reclaimed later.
> > > > So the reclaim order is A, B, ...(maybe other pages), A+1, A+2 ...
> > >
> > > I don't see your code yet but have a question.
> > > You mitigate this problem by 4/5 which could add subpages into lru tail
> > > so subpages would reclaim next interation of reclaim.
> > >
> > > What do we need 5/5?
> > > Do I miss something?
> > Both patches are required. without this patch, current page reclaim will
> > only reclaim the first page of a huge page, because the hugepage isn't
> > split yet. The hugepage is split when the first page is being written to
> > swap, which is too later and page reclaim might already isolated a lot
> > of pages.
>
> When split happens, subpages would be located in tail of LRU by your 4/5.
> (Assume tail of LRU is old age).
yes, but a lot of other pages already isolated. we will reclaim those
pages first. for example, reclaim huge page A, B. current reclaim order
is A, B, A+1, ... B+1, because we will isolated A and B first, all tail
pages are not isolated yet. While with my patch, the order is A, A
+1, ... B, B+1,.... with my patch, we can avoid unnecessary page split
or page isolation. This is exactly why my patch reduces the thp_split
count.
> In addtion, isolation happens 32 page chunk so the subpages would be isolated
> and reclaimed in next iteration. I think 32 pages are not too many.
>
> What do you think about it?
since headpage and tailpages are in different list, the 32 chunk will
not include tailpages.
--
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>
next prev parent reply other threads:[~2011-10-28 8:18 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 2:59 [patch 5/5]thp: split huge page if head page is isolated Shaohua Li
2011-10-25 2:59 ` Shaohua Li
2011-10-27 23:34 ` Minchan Kim
2011-10-27 23:34 ` Minchan Kim
2011-10-28 5:11 ` Shaohua Li
2011-10-28 5:11 ` Shaohua Li
2011-10-28 7:30 ` Minchan Kim
2011-10-28 7:30 ` Minchan Kim
2011-10-28 8:25 ` Shaohua Li [this message]
2011-10-28 8:25 ` Shaohua Li
2011-10-28 9:50 ` Minchan Kim
2011-10-28 9:50 ` Minchan Kim
2011-10-31 1:10 ` Shaohua Li
2011-10-31 1:10 ` Shaohua Li
2011-10-31 8:24 ` Minchan Kim
2011-10-31 8:24 ` Minchan Kim
2011-10-29 0:06 ` Minchan Kim
2011-10-29 0:06 ` Minchan Kim
2011-10-31 1:21 ` Shaohua Li
2011-10-31 1:21 ` Shaohua Li
2011-10-31 8:23 ` Minchan Kim
2011-10-31 8:23 ` Minchan Kim
2011-10-31 9:03 ` Shaohua Li
2011-10-31 9:03 ` Shaohua Li
2011-11-02 3:17 ` Shaohua Li
2011-11-02 3:17 ` Shaohua Li
2011-11-08 8:59 ` Minchan Kim
2011-11-08 8:59 ` Minchan Kim
2011-11-09 5:27 ` Shaohua Li
2011-11-09 5:27 ` Shaohua Li
2011-11-09 6:28 ` Minchan Kim
2011-11-09 6:28 ` Minchan Kim
2011-11-09 7:08 ` Shaohua Li
2011-11-09 7:08 ` Shaohua Li
2011-11-10 2:07 ` Shaohua Li
2011-11-10 2:07 ` Shaohua Li
2011-11-10 2:23 ` Minchan Kim
2011-11-10 2:23 ` Minchan Kim
2011-11-10 2:46 ` Shaohua Li
2011-11-10 2:46 ` Shaohua Li
2011-11-10 3:18 ` Minchan Kim
2011-11-10 3:18 ` Minchan Kim
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=1319790356.22361.165.camel@sli10-conroe \
--to=shaohua.li@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=kamezawa.hiroyu@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=riel@redhat.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.