From: Minchan Kim <minchan.kim@gmail.com>
To: Shaohua Li <shaohua.li@intel.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: Thu, 10 Nov 2011 12:18:48 +0900 [thread overview]
Message-ID: <20111110031848.GA9974@barrios-laptop.redhat.com> (raw)
In-Reply-To: <1320893167.22361.237.camel@sli10-conroe>
On Thu, Nov 10, 2011 at 10:46:07AM +0800, Shaohua Li wrote:
> On Thu, 2011-11-10 at 10:23 +0800, Minchan Kim wrote:
> > So long contents.
> > Let's remove it.
> >
> > On Thu, Nov 10, 2011 at 10:07:10AM +0800, Shaohua Li wrote:
> >
> > <snip>
> >
> > > > > Coudn't we make both sides good?
> > > > >
> > > > > Here is my quick patch.
> > > > > How about this?
> > > > > It doesn't split THPs in page_list but still reclaims non-THPs so
> > > > > I think it doesn't changed old behavior a lot.
> > > > I like this idea, will do some test soon.
> > > hmm, this doesn't work as expected. The putback_lru_page() messes lru.
> > > This isn't a problem if the page will be written since
> > > rotate_reclaimable_page() will fix the order. I got worse data than my
> > > v2 patch, eg, more thp_fallbacks, mess lru order, more pages are
> > > scanned. We could add something like putback_lru_page_tail, but I'm not
> >
> > Hmm, It's not LRU mess problem. but it's just guessing and you might be right
> > because you have a workload and can test it.
> >
> > My guessing is that cull_mlocked reset synchronus page reclaim.
> > Could you test this patch, again?
> no, I traced it, and lru mess. putback_lru_page() adds the page to lru
> head instead of tail.
I knew LRU mess happens but I mean I am not sure the culprit is it.
>
> > And, if the problem cause by LRU mess, I think it is valuable with adding putback_lru_page_tail
> > because thp added lru_add_page_tail, too.
> I want to put all remaining pages back to lru tail if a huge page is
> split, because enough pages are reclaimed. So this needs adding
> something like putback_lru_pages_tail(), not complicated, but a lot of
> code. And if there are parallel reclaimer, we still have lru mess. My
> test already shows it. Still worthy?
If parallel reclaim happens, it can spoil everything. It's really really bad.
I perfer adding putback_lru_page_tail with isoloation trick because probably
we can use it later about pages which was not able to reclaim by some causes temporally.
>
> Thanks,
> Shaohua
>
--
Kind regards,
Minchan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan.kim@gmail.com>
To: Shaohua Li <shaohua.li@intel.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: Thu, 10 Nov 2011 12:18:48 +0900 [thread overview]
Message-ID: <20111110031848.GA9974@barrios-laptop.redhat.com> (raw)
In-Reply-To: <1320893167.22361.237.camel@sli10-conroe>
On Thu, Nov 10, 2011 at 10:46:07AM +0800, Shaohua Li wrote:
> On Thu, 2011-11-10 at 10:23 +0800, Minchan Kim wrote:
> > So long contents.
> > Let's remove it.
> >
> > On Thu, Nov 10, 2011 at 10:07:10AM +0800, Shaohua Li wrote:
> >
> > <snip>
> >
> > > > > Coudn't we make both sides good?
> > > > >
> > > > > Here is my quick patch.
> > > > > How about this?
> > > > > It doesn't split THPs in page_list but still reclaims non-THPs so
> > > > > I think it doesn't changed old behavior a lot.
> > > > I like this idea, will do some test soon.
> > > hmm, this doesn't work as expected. The putback_lru_page() messes lru.
> > > This isn't a problem if the page will be written since
> > > rotate_reclaimable_page() will fix the order. I got worse data than my
> > > v2 patch, eg, more thp_fallbacks, mess lru order, more pages are
> > > scanned. We could add something like putback_lru_page_tail, but I'm not
> >
> > Hmm, It's not LRU mess problem. but it's just guessing and you might be right
> > because you have a workload and can test it.
> >
> > My guessing is that cull_mlocked reset synchronus page reclaim.
> > Could you test this patch, again?
> no, I traced it, and lru mess. putback_lru_page() adds the page to lru
> head instead of tail.
I knew LRU mess happens but I mean I am not sure the culprit is it.
>
> > And, if the problem cause by LRU mess, I think it is valuable with adding putback_lru_page_tail
> > because thp added lru_add_page_tail, too.
> I want to put all remaining pages back to lru tail if a huge page is
> split, because enough pages are reclaimed. So this needs adding
> something like putback_lru_pages_tail(), not complicated, but a lot of
> code. And if there are parallel reclaimer, we still have lru mess. My
> test already shows it. Still worthy?
If parallel reclaim happens, it can spoil everything. It's really really bad.
I perfer adding putback_lru_page_tail with isoloation trick because probably
we can use it later about pages which was not able to reclaim by some causes temporally.
>
> Thanks,
> Shaohua
>
--
Kind regards,
Minchan Kim
--
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-11-10 3:20 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
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 [this message]
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=20111110031848.GA9974@barrios-laptop.redhat.com \
--to=minchan.kim@gmail.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=riel@redhat.com \
--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.