From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, kamezawa.hiroyu@jp.fujitsu.com,
y-goto@jp.fujitsu.com, npiggin@suse.de
Subject: Re: [PATCH] memory hotplug: run lru_add_drain_all() on each cpu
Date: Fri, 05 Dec 2008 14:08:20 +0100 [thread overview]
Message-ID: <1228482500.8392.15.camel@t60p> (raw)
In-Reply-To: <1228342567.13111.11.camel@nimitz>
On Wed, 2008-12-03 at 14:16 -0800, Dave Hansen wrote:
> I'm a bit confused why this is. Is this because the LRUs are per-zone
> and we expected !CONFIG_NUMA systems to only have LRUs sitting on the
> same (only) node as the current CPU?
>
> This doesn't make any sense, though. The pagevecs that
> drain_cpu_pagevecs() actually empties out are per-cpu.
Right, the pagevecs are per-cpu, independent from any CONFIG_NUMA
settings, and this is exactly why I would expect that lru_add_drain_all()
works on all cpus, as opposed to lru_add_drain() which works only on
the current cpu.
> This doesn't seem right to me. CONFIG_MEMORY_HOTREMOVE doesn't change
> the layout of the LRUs, unlike NUMA or UNEVICTABLE_LRU. So, I think
> this bug is more due to the hotremove code mis-expecting behavior out of
> lru_add_drain_all().
>
> Why does this not affect the other lru_add_drain_all() users?
Good question, there are only a few other users and most of them were
added just recently with the unevictable lru patches. The only exception
is migrate_prep(), but this is only called from sys_move_pages(), which
is not implemented w/o CONFIG_NUMA afaik.
As explained above, the per-cpu pagevec layout should be independent
from NUMA or UNEVICTABLE_LRU, so I guess the right thing to do here
is completely remove the #ifdef as in the patch from Kosaki Motohiro
(or at least replace it with a CONFIG_SMP as suggested by Kamezawa
Hiroyuki).
Thanks,
Gerald
WARNING: multiple messages have this Message-ID (diff)
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com, kamezawa.hiroyu@jp.fujitsu.com,
y-goto@jp.fujitsu.com, npiggin@suse.de
Subject: Re: [PATCH] memory hotplug: run lru_add_drain_all() on each cpu
Date: Fri, 05 Dec 2008 14:08:20 +0100 [thread overview]
Message-ID: <1228482500.8392.15.camel@t60p> (raw)
In-Reply-To: <1228342567.13111.11.camel@nimitz>
On Wed, 2008-12-03 at 14:16 -0800, Dave Hansen wrote:
> I'm a bit confused why this is. Is this because the LRUs are per-zone
> and we expected !CONFIG_NUMA systems to only have LRUs sitting on the
> same (only) node as the current CPU?
>
> This doesn't make any sense, though. The pagevecs that
> drain_cpu_pagevecs() actually empties out are per-cpu.
Right, the pagevecs are per-cpu, independent from any CONFIG_NUMA
settings, and this is exactly why I would expect that lru_add_drain_all()
works on all cpus, as opposed to lru_add_drain() which works only on
the current cpu.
> This doesn't seem right to me. CONFIG_MEMORY_HOTREMOVE doesn't change
> the layout of the LRUs, unlike NUMA or UNEVICTABLE_LRU. So, I think
> this bug is more due to the hotremove code mis-expecting behavior out of
> lru_add_drain_all().
>
> Why does this not affect the other lru_add_drain_all() users?
Good question, there are only a few other users and most of them were
added just recently with the unevictable lru patches. The only exception
is migrate_prep(), but this is only called from sys_move_pages(), which
is not implemented w/o CONFIG_NUMA afaik.
As explained above, the per-cpu pagevec layout should be independent
from NUMA or UNEVICTABLE_LRU, so I guess the right thing to do here
is completely remove the #ifdef as in the patch from Kosaki Motohiro
(or at least replace it with a CONFIG_SMP as suggested by Kamezawa
Hiroyuki).
Thanks,
Gerald
--
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-12-05 13:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-03 21:25 [PATCH] memory hotplug: run lru_add_drain_all() on each cpu Gerald Schaefer
2008-12-03 21:25 ` Gerald Schaefer
2008-12-03 22:16 ` Dave Hansen
2008-12-03 22:16 ` Dave Hansen
2008-12-04 0:31 ` KAMEZAWA Hiroyuki
2008-12-04 0:31 ` KAMEZAWA Hiroyuki
2008-12-04 2:14 ` [PATCH] mm: remove UP version lru_add_drain_all() KOSAKI Motohiro
2008-12-04 2:14 ` KOSAKI Motohiro
2008-12-04 2:23 ` KOSAKI Motohiro
2008-12-04 2:23 ` KOSAKI Motohiro
2008-12-04 18:01 ` Gerald Schaefer
2008-12-04 18:01 ` Gerald Schaefer
2008-12-05 13:08 ` Gerald Schaefer [this message]
2008-12-05 13:08 ` [PATCH] memory hotplug: run lru_add_drain_all() on each cpu Gerald Schaefer
2008-12-05 20:43 ` Dave Hansen
2008-12-05 20:43 ` Dave Hansen
2008-12-07 4:43 ` KOSAKI Motohiro
2008-12-07 4:43 ` KOSAKI Motohiro
2008-12-08 13:56 ` Lee Schermerhorn
2008-12-08 13:56 ` Lee Schermerhorn
2008-12-08 14:30 ` KOSAKI Motohiro
2008-12-08 14:30 ` 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=1228482500.8392.15.camel@t60p \
--to=gerald.schaefer@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=schwidefsky@de.ibm.com \
--cc=y-goto@jp.fujitsu.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.