On 2015/06/04 21:57, Xishi Qiu wrote:
This patch introduces a new struct called "mirror_info", it is used to storage
the mirror address range which reported by EFI or ACPI.
TBD: call add_mirror_info() to fill it.
Signed-off-by: Xishi Qiu
---
arch/x86/mm/numa.c | 3 +++
On 2015/06/04 21:56, Xishi Qiu wrote:
This patch introduces a new config called "CONFIG_ACPI_MIRROR_MEMORY", it is
used to on/off the feature.
Signed-off-by: Xishi Qiu
---
mm/Kconfig | 8
1 file changed, 8 insertions(+)
diff --git a/mm/Kconfig b/mm/Kconfig
index 390214d..4f2a726
On 2015/06/04 21:58, Xishi Qiu wrote:
This patch introduces a new MIGRATE_TYPES called "MIGRATE_MIRROR", it is used
to storage the mirrored pages list.
When cat /proc/pagetypeinfo, you can see the count of free mirrored blocks.
I guess you need to add Mel to CC.
e.g.
euler-linux:~ # cat
On 2015/06/04 21:56, Xishi Qiu wrote:
This patch introduces a new config called CONFIG_ACPI_MIRROR_MEMORY, it is
used to on/off the feature.
Signed-off-by: Xishi Qiu qiuxi...@huawei.com
---
mm/Kconfig | 8
1 file changed, 8 insertions(+)
diff --git a/mm/Kconfig b/mm/Kconfig
index
On 2015/06/04 22:02, Xishi Qiu wrote:
Add a new interface in path /proc/sys/vm/mirrorable. When set to 1, it means
we should allocate mirrored memory for both user and kernel processes.
Signed-off-by: Xishi Qiu qiuxi...@huawei.com
I can't see why do we need this switch. If this is set, all
On 2015/06/04 22:04, Xishi Qiu wrote:
Add the buddy system interface for address range mirroring feature.
Allocate mirrored pages in MIGRATE_MIRROR list. If there is no mirrored pages
left, use other types pages.
Signed-off-by: Xishi Qiu qiuxi...@huawei.com
---
mm/page_alloc.c | 40
On 2015/06/04 21:57, Xishi Qiu wrote:
This patch introduces a new struct called mirror_info, it is used to storage
the mirror address range which reported by EFI or ACPI.
TBD: call add_mirror_info() to fill it.
Signed-off-by: Xishi Qiu qiuxi...@huawei.com
---
arch/x86/mm/numa.c | 3 +++
On 2015/06/04 22:02, Xishi Qiu wrote:
This patch introduces a new gfp flag called __GFP_MIRROR, it is used to
allocate mirrored pages through buddy system.
Signed-off-by: Xishi Qiu qiuxi...@huawei.com
In Tony's original proposal, the motivation was to mirror all kernel memory.
Is the purpose
On 2015/06/04 21:58, Xishi Qiu wrote:
This patch introduces a new MIGRATE_TYPES called MIGRATE_MIRROR, it is used
to storage the mirrored pages list.
When cat /proc/pagetypeinfo, you can see the count of free mirrored blocks.
I guess you need to add Mel to CC.
e.g.
euler-linux:~ # cat
On 2015/06/09 19:09, Xishi Qiu wrote:
On 2015/6/9 15:06, Kamezawa Hiroyuki wrote:
On 2015/06/04 22:02, Xishi Qiu wrote:
Add a new interface in path /proc/sys/vm/mirrorable. When set to 1, it means
we should allocate mirrored memory for both user and kernel processes.
Signed-off-by: Xishi Qiu
On 2015/06/09 19:10, Xishi Qiu wrote:
On 2015/6/9 14:44, Kamezawa Hiroyuki wrote:
On 2015/06/04 21:56, Xishi Qiu wrote:
This patch introduces a new config called CONFIG_ACPI_MIRROR_MEMORY, it is
used to on/off the feature.
Signed-off-by: Xishi Qiu qiuxi...@huawei.com
---
mm/Kconfig | 8
On 2015/06/09 19:04, Xishi Qiu wrote:
On 2015/6/9 15:12, Kamezawa Hiroyuki wrote:
On 2015/06/04 22:04, Xishi Qiu wrote:
Add the buddy system interface for address range mirroring feature.
Allocate mirrored pages in MIGRATE_MIRROR list. If there is no mirrored pages
left, use other types pages
On 2015/04/25 5:01, Andrew Morton wrote:
On Fri, 24 Apr 2015 17:58:33 +0800 Gu Zheng wrote:
Since the change to the cpu <--> mapping (map the cpu to the physical
node for all possible at the boot), the node of cpu may be not present,
so we use the best near online node if the node is not
On 2015/04/25 5:01, Andrew Morton wrote:
On Fri, 24 Apr 2015 17:58:33 +0800 Gu Zheng guz.f...@cn.fujitsu.com wrote:
Since the change to the cpu -- mapping (map the cpu to the physical
node for all possible at the boot), the node of cpu may be not present,
so we use the best near online node if
On 2015/04/02 10:36, Gu Zheng wrote:
Hi Kame, TJ,
On 04/01/2015 04:30 PM, Kamezawa Hiroyuki wrote:
On 2015/04/01 12:02, Tejun Heo wrote:
On Wed, Apr 01, 2015 at 11:55:11AM +0900, Kamezawa Hiroyuki wrote:
Now, hot-added cpus will have the lowest free cpu id.
Because of this, in most
On 2015/04/01 12:02, Tejun Heo wrote:
On Wed, Apr 01, 2015 at 11:55:11AM +0900, Kamezawa Hiroyuki wrote:
Now, hot-added cpus will have the lowest free cpu id.
Because of this, in most of systems which has only cpu-hot-add, cpu-ids are
always
contiguous even after cpu hot add.
In enterprise
On 2015/04/01 12:02, Tejun Heo wrote:
On Wed, Apr 01, 2015 at 11:55:11AM +0900, Kamezawa Hiroyuki wrote:
Now, hot-added cpus will have the lowest free cpu id.
Because of this, in most of systems which has only cpu-hot-add, cpu-ids are
always
contiguous even after cpu hot add.
In enterprise
On 2015/04/02 10:36, Gu Zheng wrote:
Hi Kame, TJ,
On 04/01/2015 04:30 PM, Kamezawa Hiroyuki wrote:
On 2015/04/01 12:02, Tejun Heo wrote:
On Wed, Apr 01, 2015 at 11:55:11AM +0900, Kamezawa Hiroyuki wrote:
Now, hot-added cpus will have the lowest free cpu id.
Because of this, in most
On 2015/03/30 18:58, Gu Zheng wrote:
> Hi Kame-san,
>
> On 03/27/2015 12:31 AM, Kamezawa Hiroyuki wrote:
>
>> On 2015/03/26 13:55, Gu Zheng wrote:
>>> Hi Kame-san,
>>> On 03/26/2015 11:19 AM, Kamezawa Hiroyuki wrote:
>>>
>>>> On 201
On 2015/04/01 0:28, Tejun Heo wrote:
Hello, Kamezawa.
On Tue, Mar 31, 2015 at 03:09:05PM +0900, Kamezawa Hiroyuki wrote:
But this may be considered as API change for most hot-add users.
Hmm... Why would it be? What can that possibly break?
Now, hot-added cpus will have the lowest free
On 2015/03/30 18:49, Gu Zheng wrote:
Hi Kame-san,
On 03/27/2015 12:42 AM, Kamezawa Hiroyuki wrote:
On 2015/03/27 0:18, Tejun Heo wrote:
Hello,
On Thu, Mar 26, 2015 at 01:04:00PM +0800, Gu Zheng wrote:
wq generates the numa affinity (pool->node) for all the possible cpu's
per cpu workqu
On 2015/03/30 18:49, Gu Zheng wrote:
Hi Kame-san,
On 03/27/2015 12:42 AM, Kamezawa Hiroyuki wrote:
On 2015/03/27 0:18, Tejun Heo wrote:
Hello,
On Thu, Mar 26, 2015 at 01:04:00PM +0800, Gu Zheng wrote:
wq generates the numa affinity (pool-node) for all the possible cpu's
per cpu workqueue
On 2015/03/30 18:58, Gu Zheng wrote:
Hi Kame-san,
On 03/27/2015 12:31 AM, Kamezawa Hiroyuki wrote:
On 2015/03/26 13:55, Gu Zheng wrote:
Hi Kame-san,
On 03/26/2015 11:19 AM, Kamezawa Hiroyuki wrote:
On 2015/03/26 11:17, Gu Zheng wrote:
Previously, we build the apicid -- cpuid mapping
On 2015/04/01 0:28, Tejun Heo wrote:
Hello, Kamezawa.
On Tue, Mar 31, 2015 at 03:09:05PM +0900, Kamezawa Hiroyuki wrote:
But this may be considered as API change for most hot-add users.
Hmm... Why would it be? What can that possibly break?
Now, hot-added cpus will have the lowest free
On 2015/03/27 0:18, Tejun Heo wrote:
Hello,
On Thu, Mar 26, 2015 at 01:04:00PM +0800, Gu Zheng wrote:
wq generates the numa affinity (pool->node) for all the possible cpu's
per cpu workqueue at init stage, that means the affinity of currently un-present
ones' may be incorrect, so we need to
On 2015/03/26 13:55, Gu Zheng wrote:
> Hi Kame-san,
> On 03/26/2015 11:19 AM, Kamezawa Hiroyuki wrote:
>
>> On 2015/03/26 11:17, Gu Zheng wrote:
>>> Previously, we build the apicid <--> cpuid mapping when the cpu is present,
>>> but
>>> the rela
On 2015/03/26 13:55, Gu Zheng wrote:
Hi Kame-san,
On 03/26/2015 11:19 AM, Kamezawa Hiroyuki wrote:
On 2015/03/26 11:17, Gu Zheng wrote:
Previously, we build the apicid -- cpuid mapping when the cpu is present,
but
the relationship will be changed if the cpu/node hotplug happenned, because
On 2015/03/27 0:18, Tejun Heo wrote:
Hello,
On Thu, Mar 26, 2015 at 01:04:00PM +0800, Gu Zheng wrote:
wq generates the numa affinity (pool-node) for all the possible cpu's
per cpu workqueue at init stage, that means the affinity of currently un-present
ones' may be incorrect, so we need to
size: 192, default
> order:
> 1, min order: 0
>node 0: slabs: 6172, objs: 259224, free: 245741
>node 1: slabs: 3261, objs: 136962, free: 127656
>==
> So here we build the persistent [lapic id] <--> cpuid mapping when the cpu
> first
> present,
On 2015/03/26 11:17, Gu Zheng wrote:
> Yasuaki Ishimatsu found that with node online/offline, cpu<->node
> relationship is established. Because workqueue uses a info which was
> established at boot time, but it may be changed by node hotpluging.
>
> Once pool->node points to a stale node,
On 2015/03/26 11:17, Gu Zheng wrote:
Yasuaki Ishimatsu found that with node online/offline, cpu-node
relationship is established. Because workqueue uses a info which was
established at boot time, but it may be changed by node hotpluging.
Once pool-node points to a stale node, following
node 0: slabs: 6172, objs: 259224, free: 245741
node 1: slabs: 3261, objs: 136962, free: 127656
==
So here we build the persistent [lapic id] -- cpuid mapping when the cpu
first
present, and never change it.
Suggested-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
Signed-off
On 2015/03/05 10:23, Gu Zheng wrote:
Hi Kamazawa-san,
On 03/04/2015 01:45 PM, Kamezawa Hiroyuki wrote:
On 2015/03/03 22:18, Tejun Heo wrote:
Hello, Kame.
On Tue, Mar 03, 2015 at 03:53:46PM +0900, Kamezawa Hiroyuki wrote:
relationship between proximity domain and lapic id doesn't change
On 2015/03/04 17:03, Xishi Qiu wrote:
On 2015/3/4 11:56, Gu Zheng wrote:
Hi Xishi,
On 03/04/2015 10:52 AM, Xishi Qiu wrote:
On 2015/3/4 10:22, Xishi Qiu wrote:
On 2015/3/3 18:20, Gu Zheng wrote:
Hi Xishi,
On 03/03/2015 11:30 AM, Xishi Qiu wrote:
When hot-remove a numa node, we will
On 2015/03/05 10:23, Gu Zheng wrote:
Hi Kamazawa-san,
On 03/04/2015 01:45 PM, Kamezawa Hiroyuki wrote:
On 2015/03/03 22:18, Tejun Heo wrote:
Hello, Kame.
On Tue, Mar 03, 2015 at 03:53:46PM +0900, Kamezawa Hiroyuki wrote:
relationship between proximity domain and lapic id doesn't change
On 2015/03/04 17:03, Xishi Qiu wrote:
On 2015/3/4 11:56, Gu Zheng wrote:
Hi Xishi,
On 03/04/2015 10:52 AM, Xishi Qiu wrote:
On 2015/3/4 10:22, Xishi Qiu wrote:
On 2015/3/3 18:20, Gu Zheng wrote:
Hi Xishi,
On 03/03/2015 11:30 AM, Xishi Qiu wrote:
When hot-remove a numa node, we will
On 2015/03/03 22:18, Tejun Heo wrote:
Hello, Kame.
On Tue, Mar 03, 2015 at 03:53:46PM +0900, Kamezawa Hiroyuki wrote:
relationship between proximity domain and lapic id doesn't change.
relationship between lapic-id and cpu-id changes.
pxm <-> memory address : no change
pxm <-
On 2015/03/03 22:18, Tejun Heo wrote:
Hello, Kame.
On Tue, Mar 03, 2015 at 03:53:46PM +0900, Kamezawa Hiroyuki wrote:
relationship between proximity domain and lapic id doesn't change.
relationship between lapic-id and cpu-id changes.
pxm - memory address : no change
pxm - lapicid
On 2015/03/03 1:28, Tejun Heo wrote:
Hello,
On Mon, Mar 02, 2015 at 05:41:05PM +0900, Kamezawa Hiroyuki wrote:
Let me start from explaining current behavior.
- cpu-id is determined when a new processor(lapicid/x2apicid) is founded.
cpu-id<->nodeid relationship is _not_ re
On 2015/02/27 20:54, Tejun Heo wrote:
Hello,
On Fri, Feb 27, 2015 at 06:04:52PM +0800, Gu Zheng wrote:
Yasuaki Ishimatsu found that with node online/offline, cpu<->node
relationship is established. Because workqueue uses a info which was
established at boot time, but it may be changed by node
On 2015/03/03 1:28, Tejun Heo wrote:
Hello,
On Mon, Mar 02, 2015 at 05:41:05PM +0900, Kamezawa Hiroyuki wrote:
Let me start from explaining current behavior.
- cpu-id is determined when a new processor(lapicid/x2apicid) is founded.
cpu-id-nodeid relationship is _not_ recorded
On 2015/02/27 20:54, Tejun Heo wrote:
Hello,
On Fri, Feb 27, 2015 at 06:04:52PM +0800, Gu Zheng wrote:
Yasuaki Ishimatsu found that with node online/offline, cpu-node
relationship is established. Because workqueue uses a info which was
established at boot time, but it may be changed by node
(2014/12/17 12:22), Kamezawa Hiroyuki wrote:
(2014/12/17 10:36), Lai Jiangshan wrote:
On 12/17/2014 12:45 AM, Kamezawa Hiroyuki wrote:
With node online/offline, cpu<->node relationship is established.
Workqueue uses a info which was established at boot time but
it may be changed b
(2014/12/17 10:36), Lai Jiangshan wrote:
On 12/17/2014 12:45 AM, Kamezawa Hiroyuki wrote:
With node online/offline, cpu<->node relationship is established.
Workqueue uses a info which was established at boot time but
it may be changed by node hotpluging.
Once pool->node points to a s
hotplug, this case should be handled.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f6ad05a..59d8be5 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
- clear per-cpu-pool's pool->node at node offlining.
- set per-cpu-pool's pool->node at node onlining.
- dropped modification to get_unbound_pool()
- dropped per-cpu-pool handling at cpu online/offline.
Reported-by: Yasuaki Ishimatsu
Signed-off-by: KAMEZAWA Hiroyuki
---
include/linux/mem
This is v4. Thank you for hints/commentes to previous versions.
I think this versions only contains necessary things and not invasive.
Tested several patterns of node hotplug and seems to work well.
Changes since v3
- removed changes against get_unbound_pool()
- remvoed codes in cpu offline
(2014/12/16 17:10), Kamezawa Hiroyuki wrote:
(2014/12/16 16:49), Lai Jiangshan wrote:
On 12/15/2014 07:18 PM, Kamezawa Hiroyuki wrote:
Workqueue keeps cpu<->node relationship including all possible cpus.
The original information was made at boot but it may change when
a new node is
(2014/12/16 16:49), Lai Jiangshan wrote:
On 12/15/2014 07:18 PM, Kamezawa Hiroyuki wrote:
Workqueue keeps cpu<->node relationship including all possible cpus.
The original information was made at boot but it may change when
a new node is added.
Update information if a new node is
(2014/12/16 16:49), Lai Jiangshan wrote:
On 12/15/2014 07:18 PM, Kamezawa Hiroyuki wrote:
Workqueue keeps cpu-node relationship including all possible cpus.
The original information was made at boot but it may change when
a new node is added.
Update information if a new node is ready
(2014/12/16 17:10), Kamezawa Hiroyuki wrote:
(2014/12/16 16:49), Lai Jiangshan wrote:
On 12/15/2014 07:18 PM, Kamezawa Hiroyuki wrote:
Workqueue keeps cpu-node relationship including all possible cpus.
The original information was made at boot but it may change when
a new node is added
This is v4. Thank you for hints/commentes to previous versions.
I think this versions only contains necessary things and not invasive.
Tested several patterns of node hotplug and seems to work well.
Changes since v3
- removed changes against get_unbound_pool()
- remvoed codes in cpu offline
-pool's pool-node at node offlining.
- set per-cpu-pool's pool-node at node onlining.
- dropped modification to get_unbound_pool()
- dropped per-cpu-pool handling at cpu online/offline.
Reported-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir
hotplug, this case should be handled.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f6ad05a..59d8be5 100644
--- a/kernel/workqueue.c
(2014/12/17 10:36), Lai Jiangshan wrote:
On 12/17/2014 12:45 AM, Kamezawa Hiroyuki wrote:
With node online/offline, cpu-node relationship is established.
Workqueue uses a info which was established at boot time but
it may be changed by node hotpluging.
Once pool-node points to a stale node
(2014/12/17 12:22), Kamezawa Hiroyuki wrote:
(2014/12/17 10:36), Lai Jiangshan wrote:
On 12/17/2014 12:45 AM, Kamezawa Hiroyuki wrote:
With node online/offline, cpu-node relationship is established.
Workqueue uses a info which was established at boot time but
it may be changed by node
(2014/12/16 14:30), Lai Jiangshan wrote:
On 12/15/2014 07:14 PM, Kamezawa Hiroyuki wrote:
Unbound wq pool's node attribute is calculated at its allocation.
But it's now calculated based on possible cpu<->node information
which can be wrong after cpu hotplug/unplug.
If wrong pool->no
(2014/12/16 14:32), Lai Jiangshan wrote:
On 12/15/2014 07:16 PM, Kamezawa Hiroyuki wrote:
The percpu workqueue pool are persistend and never be freed.
But cpu<->node relationship can be changed by cpu hotplug and pool->node
can point to an offlined node.
If pool->node points to
affinity can be modified if memory-less
node turns out to be an usual node by step 2.
This patch handles the event in CPU_ONLINE callback of workqueue.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/kernel/workqueue.c b
Workqueue keeps cpu<->node relationship including all possible cpus.
The original information was made at boot but it may change when
a new node is added.
Update information if a new node is ready with using node-hotplug callback.
Signed-off-by: KAMEZAWA Hiroyuki
---
include
inity at
cpu offlining and restore it at cpu onlining.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7809154..2fd0bd7 100644
--- a/kernel/workqueue.c
+++ b/kernel
loc_unbound_pwq
wq_update_unbound_numa
called at CPU_ONLINE/CPU_DOWN_PREPARE
and the latest online cpu info can be applied to a new wq pool,
which replaces old one.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 38 ++
1 file changed, 26 insertions(+
Lai-san, Tejun-san,
Thank you for review, this a fix v3. This has been tested on NUMA node hotplug
machine and seems work well.
The probelm is memory allocation failure because pool->node information can be
stale
after node hotplug. This patch(1,2) tries to fix pool->node calculation.
Patch
Lai-san, Tejun-san,
Thank you for review, this a fix v3. This has been tested on NUMA node hotplug
machine and seems work well.
The probelm is memory allocation failure because pool-node information can be
stale
after node hotplug. This patch(1,2) tries to fix pool-node calculation.
Patch (3,4)
wq_update_unbound_numa
called at CPU_ONLINE/CPU_DOWN_PREPARE
and the latest online cpu info can be applied to a new wq pool,
which replaces old one.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 38 ++
1 file changed, 26
and restore it at cpu onlining.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7809154..2fd0bd7 100644
--- a/kernel/workqueue.c
Workqueue keeps cpu-node relationship including all possible cpus.
The original information was made at boot but it may change when
a new node is added.
Update information if a new node is ready with using node-hotplug callback.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
affinity can be modified if memory-less
node turns out to be an usual node by step 2.
This patch handles the event in CPU_ONLINE callback of workqueue.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 15 +++
1 file changed, 15 insertions(+)
diff
(2014/12/16 14:32), Lai Jiangshan wrote:
On 12/15/2014 07:16 PM, Kamezawa Hiroyuki wrote:
The percpu workqueue pool are persistend and never be freed.
But cpu-node relationship can be changed by cpu hotplug and pool-node
can point to an offlined node.
If pool-node points to an offlined node
(2014/12/16 14:30), Lai Jiangshan wrote:
On 12/15/2014 07:14 PM, Kamezawa Hiroyuki wrote:
Unbound wq pool's node attribute is calculated at its allocation.
But it's now calculated based on possible cpu-node information
which can be wrong after cpu hotplug/unplug.
If wrong pool-node is set
(2014/12/15 14:19), Lai Jiangshan wrote:
On 12/15/2014 12:04 PM, Kamezawa Hiroyuki wrote:
(2014/12/15 12:34), Lai Jiangshan wrote:
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12
(2014/12/15 12:34), Lai Jiangshan wrote:
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes do
(2014/12/15 11:06), Lai Jiangshan wrote:
On 12/14/2014 12:35 AM, Kamezawa Hiroyuki wrote:
remove node aware unbound pools if node goes offline.
scan unbound workqueue and remove numa affine pool when
a node goes offline.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 29
(2014/12/15 11:06), Lai Jiangshan wrote:
On 12/14/2014 12:35 AM, Kamezawa Hiroyuki wrote:
remove node aware unbound pools if node goes offline.
scan unbound workqueue and remove numa affine pool when
a node goes offline.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu-node at boot,
it is finally determined in cpu_up().
This patch tries to update pool-node using online status of cpus.
1. When a node goes down, clear
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu-node at boot,
it is finally determined in cpu_up
(2014/12/15 12:34), Lai Jiangshan wrote:
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue
(2014/12/15 14:19), Lai Jiangshan wrote:
On 12/15/2014 12:04 PM, Kamezawa Hiroyuki wrote:
(2014/12/15 12:34), Lai Jiangshan wrote:
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12
.
3. When a cpu comes up, update possinle node cpumask workqueue is using for
sched.
4. Detect the best node for unbound pool's cpumask using the latest info.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 67 ++
1 file changed, 53 i
remove node aware unbound pools if node goes offline.
scan unbound workqueue and remove numa affine pool when
a node goes offline.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/kernel/workqueue.c b
Yasuaki Ishimatsu hit a allocation failure bug when the numa mapping
between CPU and node is changed. This was the last scene:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172,
Add warning if pool->node is offline.
This patch was originaly made for debug.
I think add warning here can show what may happen.
Signed-off-by: KAMEZAWA Hiroyuki
---
kernel/workqueue.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.
ode hotplug.
Signed-off-by: KAMEZAWA Hiroyuki node should be cleared and
+ * cached pools per cpu should be freed at node unplug
+ */
+
+void workqueue_register_numanode(int nid)
+{
+}
+
+void workqueue_unregister_numanode(int nid)
+{
+}
+#endif
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplu
hotplug.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
include/linux/workqueue.h | 6 ++
kernel/workqueue.c| 18 ++
mm/memory_hotplug.c | 9 +++--
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/include/linux/workqueue.h b
Add warning if pool-node is offline.
This patch was originaly made for debug.
I think add warning here can show what may happen.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff
Yasuaki Ishimatsu hit a allocation failure bug when the numa mapping
between CPU and node is changed. This was the last scene:
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmalloc-192, object size: 192, buffer size: 192, default order: 1, min
order: 0
node 0: slabs: 6172,
remove node aware unbound pools if node goes offline.
scan unbound workqueue and remove numa affine pool when
a node goes offline.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 29 +
1 file changed, 29 insertions(+)
diff
a cpu comes up, update possinle node cpumask workqueue is using for
sched.
4. Detect the best node for unbound pool's cpumask using the latest info.
Signed-off-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
---
kernel/workqueue.c | 67 ++
1
(2014/10/31 18:46), Tang Chen wrote:
> When we are doing memory hot-add, the following functions are called:
>
> add_memory()
> |--> hotadd_new_pgdat()
> |--> free_area_init_node()
>|--> free_area_init_core()
> |--> zone->present_pages = realsize; /* 1.
(2014/11/02 12:15), Johannes Weiner wrote:
> Now that the external page_cgroup data structure and its lookup is
> gone, let the generic bad_page() check for page->mem_cgroup sanity.
>
> Signed-off-by: Johannes Weiner
Acked-by: KAMEZAWA Hiroyuki
--
To unsubscribe from this list
nes Weiner
Acked-by: KAMEZAWA Hiroyuki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----
> 8 files changed, 41 insertions(+), 487 deletions(-)
>
Great!
Acked-by: KAMEZAWA Hiroyuki
BTW, init/Kconfig comments shouldn't be updated ?
(I'm sorry if it has been updated since your latest fix.)
--
To unsubscribe from this list: send the line &
-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
BTW, init/Kconfig comments shouldn't be updated ?
(I'm sorry if it has been updated since your latest fix.)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org
(2014/11/02 12:15), Johannes Weiner wrote:
Now that the external page_cgroup data structure and its lookup is
gone, let the generic bad_page() check for page-mem_cgroup sanity.
Signed-off-by: Johannes Weiner han...@cmpxchg.org
Acked-by: KAMEZAWA Hiroyuki kamezawa.hir...@jp.fujitsu.com
(2014/10/31 18:46), Tang Chen wrote:
When we are doing memory hot-add, the following functions are called:
add_memory()
|-- hotadd_new_pgdat()
|-- free_area_init_node()
|-- free_area_init_core()
|-- zone-present_pages = realsize; /* 1. zone is
ter the final LRU removal. Uncharge can simply clear the
> pointer and the PCG_USED/PageCgroupUsed sites can test that instead.
>
> Because this is the last page_cgroup flag, this patch reduces the
> memcg per-page overhead to a single pointer.
>
> Signed-off-by: Johannes We
rsion, mem_cgroup_migrate() directly uncharges the
> source page, rendering this distinction unnecessary. Remove it.
>
> Signed-off-by: Johannes Weiner
Acked-by: KAMEZAWA Hiroyuki
> ---
> include/linux/page_cgroup.h | 1 -
> mm/memcontrol.c | 4 +---
>
101 - 200 of 1415 matches
Mail list logo
