From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux-foundation.org>,
heiko.carstens@de.ibm.com, npiggin@suse.de,
linux-kernel@vger.kernel.org, hugh@veritas.com,
torvalds@linux-foundation.org, riel@redhat.com,
lee.schermerhorn@hp.com, linux-mm@kvack.org
Subject: Re: [RFC][PATCH] lru_add_drain_all() don't use schedule_on_each_cpu()
Date: Wed, 29 Oct 2008 17:21:57 +0900 [thread overview]
Message-ID: <20081029172157.080de70b.kamezawa.hiroyu@jp.fujitsu.com> (raw)
In-Reply-To: <2f11576a0810290020i362441edkb494b10c10b17401@mail.gmail.com>
On Wed, 29 Oct 2008 16:20:24 +0900
"KOSAKI Motohiro" <kosaki.motohiro@jp.fujitsu.com> wrote:
> > I guess we should document our newly discovered schedule_on_each_cpu()
> > problems before we forget about it and later rediscover it.
>
> Now, schedule_on_each_cpu() is only used by lru_add_drain_all().
> and smp_call_function() is better way for cross call.
>
> So I propose
> 1. lru_add_drain_all() use smp_call_function()
IMHO, smp_call_function() is not good, either.
The real problem in this lru_add_drain_all() around mlock() is handling of
pagevec. How about attached one ?(not tested at all..just an idea.)
> 2. remove schedule_on_each_cpu()
>
I'm using schedule_on_each_cpu() from not dangerous context (in new memcg patch..)
Thanks,
-Kame
==
pagevec is used for avoidning lru_lock contention for add/remove pages to/from
LRU. But under split-lru/unevictable lru world, this delay in pagevec can
cause unexpected behavior.
* A page scheduled to add to Unevictable lru is unlocked
while it's in pagevec.
Because a page wrongly linked to Unevictable lru cannot come back to usual
lru, this is a problem. To avoid this kind of situation, lru_add_drain_all()
is called from mlock() path.
This patch remove "delay" of pagevec for Unevictable pages and remove
lru_add_drain_all(), which is a burtal function should not be called from
deep under the kernel.
---
mm/mlock.c | 13 ++-----------
mm/swap.c | 17 +++++++++++++----
2 files changed, 15 insertions(+), 15 deletions(-)
Index: mmotm-2.6.27+/mm/mlock.c
===================================================================
--- mmotm-2.6.27+.orig/mm/mlock.c
+++ mmotm-2.6.27+/mm/mlock.c
@@ -66,14 +66,9 @@ void __clear_page_mlock(struct page *pag
putback_lru_page(page);
} else {
/*
- * Page not on the LRU yet. Flush all pagevecs and retry.
+ * Page not on the LRU yet.
+ * pagevec will handle this in proper way.
*/
- lru_add_drain_all();
- if (!isolate_lru_page(page))
- putback_lru_page(page);
- else if (PageUnevictable(page))
- count_vm_event(UNEVICTABLE_PGSTRANDED);
-
}
}
@@ -187,8 +182,6 @@ static long __mlock_vma_pages_range(stru
if (vma->vm_flags & VM_WRITE)
gup_flags |= GUP_FLAGS_WRITE;
- lru_add_drain_all(); /* push cached pages to LRU */
-
while (nr_pages > 0) {
int i;
@@ -251,8 +244,6 @@ static long __mlock_vma_pages_range(stru
ret = 0;
}
- lru_add_drain_all(); /* to update stats */
-
return ret; /* count entire vma as locked_vm */
}
Index: mmotm-2.6.27+/mm/swap.c
===================================================================
--- mmotm-2.6.27+.orig/mm/swap.c
+++ mmotm-2.6.27+/mm/swap.c
@@ -200,10 +200,19 @@ void __lru_cache_add(struct page *page,
{
struct pagevec *pvec = &get_cpu_var(lru_add_pvecs)[lru];
- page_cache_get(page);
- if (!pagevec_add(pvec, page))
- ____pagevec_lru_add(pvec, lru);
- put_cpu_var(lru_add_pvecs);
+ if (likely(lru != LRU_UNEVICTABLE)) {
+ page_cache_get(page);
+ if (!pagevec_add(pvec, page))
+ ____pagevec_lru_add(pvec, lru);
+ put_cpu_var(lru_add_pvecs);
+ } else {
+ /*
+ * A page put into Unevictable List has no chance to come back
+ * to other LRU.(it can be unlocked while in pagevec.)
+ * We do add_to_lru in synchrous way.
+ */
+ add_page_to_unevictable_list(page);
+ }
}
/**
--
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:[~2008-10-29 8:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200810201659.m9KGxtFC016280@hera.kernel.org>
2008-10-21 15:13 ` mlock: mlocked pages are unevictable Heiko Carstens
2008-10-21 15:51 ` KOSAKI Motohiro
2008-10-21 17:18 ` KOSAKI Motohiro
2008-10-21 20:30 ` Peter Zijlstra
2008-10-21 20:48 ` Peter Zijlstra
2008-10-23 15:00 ` [RFC][PATCH] lru_add_drain_all() don't use schedule_on_each_cpu() KOSAKI Motohiro
2008-10-24 1:28 ` Nick Piggin
2008-10-24 4:54 ` KOSAKI Motohiro
2008-10-24 4:55 ` Nick Piggin
2008-10-24 5:29 ` KOSAKI Motohiro
2008-10-24 5:34 ` Nick Piggin
2008-10-24 5:51 ` KOSAKI Motohiro
2008-10-24 19:20 ` Heiko Carstens
2008-10-26 11:06 ` Peter Zijlstra
2008-10-26 13:37 ` KOSAKI Motohiro
2008-10-26 13:49 ` Peter Zijlstra
2008-10-26 15:51 ` KOSAKI Motohiro
2008-10-26 16:17 ` Peter Zijlstra
2008-10-27 3:14 ` KOSAKI Motohiro
2008-10-27 7:56 ` Peter Zijlstra
2008-10-27 8:03 ` KOSAKI Motohiro
2008-10-27 10:42 ` KOSAKI Motohiro
2008-10-27 21:55 ` Andrew Morton
2008-10-28 14:25 ` Christoph Lameter
2008-10-28 20:45 ` Andrew Morton
2008-10-28 21:29 ` Lee Schermerhorn
2008-10-29 7:17 ` KOSAKI Motohiro
2008-10-29 12:40 ` Lee Schermerhorn
2008-11-06 0:14 ` [PATCH] get rid of lru_add_drain_all() in munlock path KOSAKI Motohiro
2008-11-06 16:33 ` Kamalesh Babulal
2008-10-29 7:20 ` [RFC][PATCH] lru_add_drain_all() don't use schedule_on_each_cpu() KOSAKI Motohiro
2008-10-29 8:21 ` KAMEZAWA Hiroyuki [this message]
2008-11-05 9:51 ` Peter Zijlstra
2008-11-05 9:55 ` KOSAKI Motohiro
2008-10-22 15:28 ` mlock: mlocked pages are unevictable Lee Schermerhorn
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=20081029172157.080de70b.kamezawa.hiroyu@jp.fujitsu.com \
--to=kamezawa.hiroyu@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=heiko.carstens@de.ibm.com \
--cc=hugh@veritas.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=lee.schermerhorn@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox