lowing "Fixes:" tag in the description.
Fixes: 30bb9811856f ("x86/topology: Avoid wasting 128k for package id array")
Thanks,
Yasuaki Ishimatsu
On 02/05/2018 10:51 PM, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma <m.miz...@jp.fujitsu.com>
>
> When a p
" tag in the description.
Fixes: 30bb9811856f ("x86/topology: Avoid wasting 128k for package id array")
Thanks,
Yasuaki Ishimatsu
On 02/05/2018 10:51 PM, Masayoshi Mizuma wrote:
> From: Masayoshi Mizuma
>
> When a physical cpu is hot-removed, the following warning message
> a
still think 12M is large. But the latest Fujitsu server
supports 448 CPUs.
The issue may occur with trace_buf_size=10M on the system. Additionally the
number of CPU
in a server is increasing year by year. So the issue will occurs even if we
don't specify
large trace buffer.
Thanks,
Yasuaki Ishimatsu
still think 12M is large. But the latest Fujitsu server
supports 448 CPUs.
The issue may occur with trace_buf_size=10M on the system. Additionally the
number of CPU
in a server is increasing year by year. So the issue will occurs even if we
don't specify
large trace buffer.
Thanks,
Yasuaki Ishimatsu
[5.028681] node 6 initialised, 15982779 pages in 673ms
[5.716102] node 7 initialised, 15987304 pages in 687ms
[5.727855] smp: Bringing up secondary CPUs ...
[5.745937] x86: Booting SMP configuration:
Thanks,
Yasuaki Ishimatsu
On 11/14/2017 06:46 AM, Mel Gorman wrote:
> On Mon, Nov
[5.028681] node 6 initialised, 15982779 pages in 673ms
[5.716102] node 7 initialised, 15987304 pages in 687ms
[5.727855] smp: Bringing up secondary CPUs ...
[5.745937] x86: Booting SMP configuration:
Thanks,
Yasuaki Ishimatsu
On 11/14/2017 06:46 AM, Mel Gorman wrote:
> On Mon, Nov
On 11/14/2017 10:53 AM, Mel Gorman wrote:
> On Tue, Nov 14, 2017 at 10:39:19AM -0500, YASUAKI ISHIMATSU wrote:
>>
>>
>> On 11/14/2017 06:46 AM, Mel Gorman wrote:
>>> On Mon, Nov 13, 2017 at 12:48:36PM -0500, YASUAKI ISHIMATSU wrote:
>>>> When using trac
On 11/14/2017 10:53 AM, Mel Gorman wrote:
> On Tue, Nov 14, 2017 at 10:39:19AM -0500, YASUAKI ISHIMATSU wrote:
>>
>>
>> On 11/14/2017 06:46 AM, Mel Gorman wrote:
>>> On Mon, Nov 13, 2017 at 12:48:36PM -0500, YASUAKI ISHIMATSU wrote:
>>>> When using trac
On 11/14/2017 06:46 AM, Mel Gorman wrote:
> On Mon, Nov 13, 2017 at 12:48:36PM -0500, YASUAKI ISHIMATSU wrote:
>> When using trace_buf_size= boot option, memory allocation of ring buffer
>> for trace fails as follows:
>>
>> [ ] x86: Booting SMP configurat
On 11/14/2017 06:46 AM, Mel Gorman wrote:
> On Mon, Nov 13, 2017 at 12:48:36PM -0500, YASUAKI ISHIMATSU wrote:
>> When using trace_buf_size= boot option, memory allocation of ring buffer
>> for trace fails as follows:
>>
>> [ ] x86: Booting SMP configurat
o allocation failure occurs.
Thanks,
Yasuaki Ishimatsu
o allocation failure occurs.
Thanks,
Yasuaki Ishimatsu
t; smpboot_thread_fn
=> kthread
=> ret_from_fork
<...>-1322 [187] d..1 1300.660985: irq_do_set_affinity: irq: 127
ret 2 mask: 186-187 eff: 186
<...>-1322 [187] d..1 1300.660993:
=> native_cpu_disable
=> take_cpu_down
=> multi_cpu_stop
=> cpu_sto
t; smpboot_thread_fn
=> kthread
=> ret_from_fork
<...>-1322 [187] d..1 1300.660985: irq_do_set_affinity: irq: 127
ret 2 mask: 186-187 eff: 186
<...>-1322 [187] d..1 1300.660993:
=> native_cpu_disable
=> take_cpu_down
=> multi_cpu_stop
=> cpu_sto
Hi Thomas,
Sorry for the late reply.
I'll apply the patches and retest in this week.
Please wait a while.
Thanks,
Yasuaki Ishimatsu
On 10/04/2017 05:04 PM, Thomas Gleixner wrote:
> On Tue, 3 Oct 2017, Thomas Gleixner wrote:
>> Can you please apply the debug patch below.
>
> I
Hi Thomas,
Sorry for the late reply.
I'll apply the patches and retest in this week.
Please wait a while.
Thanks,
Yasuaki Ishimatsu
On 10/04/2017 05:04 PM, Thomas Gleixner wrote:
> On Tue, 3 Oct 2017, Thomas Gleixner wrote:
>> Can you please apply the debug patch below.
>
> I
On 09/16/2017 11:02 AM, Thomas Gleixner wrote:
> On Sat, 16 Sep 2017, Thomas Gleixner wrote:
>> On Thu, 14 Sep 2017, YASUAKI ISHIMATSU wrote:
>>> Here are one irq's info of megasas:
>>>
>>> - Before offline CPU
>>> /proc/irq/70/smp_affinity_list
>
On 09/16/2017 11:02 AM, Thomas Gleixner wrote:
> On Sat, 16 Sep 2017, Thomas Gleixner wrote:
>> On Thu, 14 Sep 2017, YASUAKI ISHIMATSU wrote:
>>> Here are one irq's info of megasas:
>>>
>>> - Before offline CPU
>>> /proc/irq/70/smp_affinity_list
>
bit value, the patch defines find_{smallest|biggest}_section_pfn()
as unsigned long.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
---
mm/memory_hotplug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
bit value, the patch defines find_{smallest|biggest}_section_pfn()
as unsigned long.
Signed-off-by: Yasuaki Ishimatsu
---
mm/memory_hotplug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 38c3c37..120e45b 100644
--- a/mm
and section_nr_to_pfn() does not calculate
correct pfn.
To make callers use proper arg, the patch changes the macros to
inline functions.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
---
include/linux/mmzone.h | 10 --
mm/memory_hotplug.c| 2 +-
2 files changed, 9 inse
and section_nr_to_pfn() does not calculate
correct pfn.
To make callers use proper arg, the patch changes the macros to
inline functions.
Signed-off-by: Yasuaki Ishimatsu
---
include/linux/mmzone.h | 10 --
mm/memory_hotplug.c| 2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git
On 09/13/2017 09:33 AM, Thomas Gleixner wrote:
> On Wed, 13 Sep 2017, Kashyap Desai wrote:
>>> On 09/12/2017 08:15 PM, YASUAKI ISHIMATSU wrote:
>>>> + linux-scsi and maintainers of megasas
>
>>>>> In my server, IRQ#66-89 are sent to CPU#24-29. And if I
On 09/13/2017 09:33 AM, Thomas Gleixner wrote:
> On Wed, 13 Sep 2017, Kashyap Desai wrote:
>>> On 09/12/2017 08:15 PM, YASUAKI ISHIMATSU wrote:
>>>> + linux-scsi and maintainers of megasas
>
>>>>> In my server, IRQ#66-89 are sent to CPU#24-29. And if I
Hi Michal,
On 09/13/2017 01:59 AM, Michal Hocko wrote:
> On Tue 12-09-17 13:05:39, YASUAKI ISHIMATSU wrote:
>> Hi Michal,
>>
>> Thanks you for reviewing my patch.
>>
>> On 09/12/2017 08:49 AM, Michal Hocko wrote:
>>> On Fri 08-09-17 16:43:04, YASUAKI ISHI
Hi Michal,
On 09/13/2017 01:59 AM, Michal Hocko wrote:
> On Tue 12-09-17 13:05:39, YASUAKI ISHIMATSU wrote:
>> Hi Michal,
>>
>> Thanks you for reviewing my patch.
>>
>> On 09/12/2017 08:49 AM, Michal Hocko wrote:
>>> On Fri 08-09-17 16:43:04, YASUAKI ISHI
+ linux-scsi and maintainers of megasas
When offlining CPU, I/O stops. Do you have any ideas?
On 09/07/2017 04:23 PM, YASUAKI ISHIMATSU wrote:
> Hi Mark and Christoph,
>
> Sorry for the late reply. I appreciated that you fixed the issue on kvm
> environment.
> But the iss
+ linux-scsi and maintainers of megasas
When offlining CPU, I/O stops. Do you have any ideas?
On 09/07/2017 04:23 PM, YASUAKI ISHIMATSU wrote:
> Hi Mark and Christoph,
>
> Sorry for the late reply. I appreciated that you fixed the issue on kvm
> environment.
> But the iss
Hi Michal,
Thanks you for reviewing my patch.
On 09/12/2017 08:49 AM, Michal Hocko wrote:
> On Fri 08-09-17 16:43:04, YASUAKI ISHIMATSU wrote:
>> __remove_section() calls __remove_zone() to shrink zone and pgdat.
>> But due to wrong castings, __remvoe_zone() cannot shrink zo
Hi Michal,
Thanks you for reviewing my patch.
On 09/12/2017 08:49 AM, Michal Hocko wrote:
> On Fri 08-09-17 16:43:04, YASUAKI ISHIMATSU wrote:
>> __remove_section() calls __remove_zone() to shrink zone and pgdat.
>> But due to wrong castings, __remvoe_zone() cannot shrink zo
. __remove_section() calculates start_pfn using section_nr_to_pfn()
and scn_nr. section_nr_to_pfn() just shifts scn_nr by
PFN_SECTION_SHIFT bit. But since scn_nr is defined as int,
section_nr_to_pfn() always return 32 bit value.
The patch fixes the wrong castings.
Signed-off-by: Yasuaki Ishimatsu
. __remove_section() calculates start_pfn using section_nr_to_pfn()
and scn_nr. section_nr_to_pfn() just shifts scn_nr by
PFN_SECTION_SHIFT bit. But since scn_nr is defined as int,
section_nr_to_pfn() always return 32 bit value.
The patch fixes the wrong castings.
Signed-off-by: Yasuaki Ishimatsu
0
[...] R13: 7f0bd751f9c0 R14: 7f0bd751f700 R15:
---
Thanks,
Yasuaki Ishimatsu
On 08/21/2017 09:37 AM, Marc Zyngier wrote:
> On 21/08/17 14:18, Christoph Hellwig wrote:
>> Can you try the patch below please?
>>
>> ---
>> From d5f59cb7a62
0
[...] R13: 7f0bd751f9c0 R14: 7f0bd751f700 R15:
---
Thanks,
Yasuaki Ishimatsu
On 08/21/2017 09:37 AM, Marc Zyngier wrote:
> On 21/08/17 14:18, Christoph Hellwig wrote:
>> Can you try the patch below please?
>>
>> ---
>> From d5f59cb7a62
Hi Marc,
On 08/09/2017 07:42 AM, Marc Zyngier wrote:
> On Tue, 8 Aug 2017 15:25:35 -0400
> YASUAKI ISHIMATSU <yasu.isim...@gmail.com> wrote:
>
>> Hi Thomas,
>>
>> When offlining all CPUs except cpu0, system hung up with the following
>> message.
>
Hi Marc,
On 08/09/2017 07:42 AM, Marc Zyngier wrote:
> On Tue, 8 Aug 2017 15:25:35 -0400
> YASUAKI ISHIMATSU wrote:
>
>> Hi Thomas,
>>
>> When offlining all CPUs except cpu0, system hung up with the following
>> message.
>>
>> [...] INFO: task
ddress. Is this required by the current hot-plug memory code?
>>>>>>
>>>>>
>>>>> Wow! So great, It seems this is required by the hot-plug memory code.
>>>>>
>>>>> yesterday, I tested the patch in Qemu with 4 node and e
ddress. Is this required by the current hot-plug memory code?
>>>>>>
>>>>>
>>>>> Wow! So great, It seems this is required by the hot-plug memory code.
>>>>>
>>>>> yesterday, I tested the patch in Qemu with 4 node and e
/cpuhotplug: Handle managed IRQs on CPU hotplug
Thanks,
Yasuaki Ishimatsu
d IRQs on CPU hotplug
Thanks,
Yasuaki Ishimatsu
/cpuhotplug: Handle managed IRQs on CPU hotplug
Thanks,
Yasuaki Ishimatsu
d IRQs on CPU hotplug
Thanks,
Yasuaki Ishimatsu
gt;>>>> But actually, we should have 4G normally.
>>>>
>>>> So do you have assumption on the order of immovable nodes and movable
>>>> nodes? E.g above your example of nodes, immovable nodes have to be the
>>>> lowest address. Is this required
gt;>>>> But actually, we should have 4G normally.
>>>>
>>>> So do you have assumption on the order of immovable nodes and movable
>>>> nodes? E.g above your example of nodes, immovable nodes have to be the
>>>> lowest address. Is this required
On 08/02/2017 01:49 AM, joeyli wrote:
> Hi YASUAKI,
>
> On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote:
>> Hi Joey,
>>
>> On 07/23/2017 05:18 AM, joeyli wrote:
> [...snip]
>>>>>
>>>>
>>>> At least Yas
On 08/02/2017 01:49 AM, joeyli wrote:
> Hi YASUAKI,
>
> On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote:
>> Hi Joey,
>>
>> On 07/23/2017 05:18 AM, joeyli wrote:
> [...snip]
>>>>>
>>>>
>>>> At least Yas
e I do not see how it
>>> fits into the container and online/offline scenario.
>>>
>>
>> At least Yasuaki raised similar behavior for container in 2013.
>> It's similar to the DVD player case, user space application needs
>> to do something then trigger children
e I do not see how it
>>> fits into the container and online/offline scenario.
>>>
>>
>> At least Yasuaki raised similar behavior for container in 2013.
>> It's similar to the DVD player case, user space application needs
>> to do something then trigger children
mation, the issue does not occur if I just do memory hot-add.
But if I hot add the memory after hot removing a memory, the issue occurs 100%.
Thanks,
Yasuaki Ishimatsu
just do memory hot-add.
But if I hot add the memory after hot removing a memory, the issue occurs 100%.
Thanks,
Yasuaki Ishimatsu
erspace is responsible for the whole container offlining.
Thanks,
Yasuaki Ishimatsu
`
>
> - After a couple of years, can we let the container hot-remove
>process transparently?
> - Except udev rule, does there have any other mechanism to trigger
>auto offline/ejectio
erspace is responsible for the whole container offlining.
Thanks,
Yasuaki Ishimatsu
`
>
> - After a couple of years, can we let the container hot-remove
>process transparently?
> - Except udev rule, does there have any other mechanism to trigger
>auto offline/ejectio
Kernel can't be randomized to be above the limit.
I confirmed that mem= works correctly.
Tested-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Thanks,
Yasuaki Ishimatsu
>
> *) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.
>
> This patchset tr
Kernel can't be randomized to be above the limit.
I confirmed that mem= works correctly.
Tested-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
>
> *) kernel-parameters.txt doesn't tell the updated behaviour of memmap=.
>
> This patchset tries to solve above issues, and it
l change
>
> Signed-off-by: Michal Hocko <mho...@suse.com>
> ---
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Thanks,
Yasuaki Ishimatsu
> mm/memory_hotplug.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff
ned-off-by: Michal Hocko
> ---
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
> mm/memory_hotplug.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 9ed251811ec3..342332f29364 100
simplify all callers.
>
> This patch shouldn't have any visible effect
>
> Signed-off-by: Michal Hocko <mho...@suse.com>
> ---
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Thanks,
Yasuaki Ishimatsu
> include/linux/mmzone.h | 2 +-
> mm/memory_hotplu
This patch shouldn't have any visible effect
>
> Signed-off-by: Michal Hocko
> ---
Reviewed-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
> include/linux/mmzone.h | 2 +-
> mm/memory_hotplug.c| 23 +--
> mm/page_alloc.c| 8 ++--
On 03/13/2017 05:19 AM, Michal Hocko wrote:
On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote:
On 03/10/2017 08:58 AM, Michal Hocko wrote:
[...]
OK so I did with -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G
which generated
[...]
[0.00] ACPI: SRAT: Node 0 PXM 0 [mem
On 03/13/2017 05:19 AM, Michal Hocko wrote:
On Fri 10-03-17 12:39:27, Yasuaki Ishimatsu wrote:
On 03/10/2017 08:58 AM, Michal Hocko wrote:
[...]
OK so I did with -m 2G,slots=4,maxmem=4G -numa node,mem=1G -numa node,mem=1G
which generated
[...]
[0.00] ACPI: SRAT: Node 0 PXM 0 [mem
it seems to have made management of
these zone structs simple.
Thanks,
Yasuaki Ishimatsu
This would explain why onlining from the last block actually works but
to me this sounds like a completely crappy behavior. All we need to
guarantee AFAICS is that Normal and Movable zones do not overlap
ement of
these zone structs simple.
Thanks,
Yasuaki Ishimatsu
This would explain why onlining from the last block actually works but
to me this sounds like a completely crappy behavior. All we need to
guarantee AFAICS is that Normal and Movable zones do not overlap. I
believe there is even no real
TAB was replaced to white spaces. So please apply this one.
---
From: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Date: Fri, 3 Feb 2017 15:18:03 -0500
Subject: [PATCH] mm/memory_hotplug: Remove unnecessary code from
get_page_bootmem()
The following patch is not applied correctly
TAB was replaced to white spaces. So please apply this one.
---
From: Yasuaki Ishimatsu
Date: Fri, 3 Feb 2017 15:18:03 -0500
Subject: [PATCH] mm/memory_hotplug: Remove unnecessary code from
get_page_bootmem()
The following patch is not applied correctly.
http://lkml.kernel.org/r/2c29bd9f
Hi Andrew,
Please apply the following patch into your tree because patch
("mm/memory_hotplug: set magic number to page->freelsit instead of
page->lru.next")
is not applied correctly.
---
From: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Date: Fri, 3 Feb 2017
Hi Andrew,
Please apply the following patch into your tree because patch
("mm/memory_hotplug: set magic number to page->freelsit instead of
page->lru.next")
is not applied correctly.
---
From: Yasuaki Ishimatsu
Date: Fri, 3 Feb 2017 15:18:03 -0500
Subject: [PATCH] Remove unnec
(+), 178 deletions(-)
I tested physical CPU hot-add and remove with your patch-set.
And I confirmed that the patch-set works good to me.
Tested-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Thanks,
Yasuaki Ishimatsu
(+), 178 deletions(-)
I tested physical CPU hot-add and remove with your patch-set.
And I confirmed that the patch-set works good to me.
Tested-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
On 01/30/2017 11:56 AM, Thomas Gleixner wrote:
On Mon, 30 Jan 2017, Yasuaki Ishimatsu wrote:
Hi Thomas,
Do you have any idea to fix the issue?
If you have the idea, please send me the patch.
Yes, I have a patch, but need to do some tests and get changelogs
written. Will keep you updated
On 01/30/2017 11:56 AM, Thomas Gleixner wrote:
On Mon, 30 Jan 2017, Yasuaki Ishimatsu wrote:
Hi Thomas,
Do you have any idea to fix the issue?
If you have the idea, please send me the patch.
Yes, I have a patch, but need to do some tests and get changelogs
written. Will keep you updated
Hi Thomas,
Do you have any idea to fix the issue?
If you have the idea, please send me the patch.
Thanks,
Yasuaki Ishimatsu
On 01/24/2017 02:54 PM, Thomas Gleixner wrote:
On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote:
rapl_cpu_prepare() must be called after logical package id of CPU
is set
Hi Thomas,
Do you have any idea to fix the issue?
If you have the idea, please send me the patch.
Thanks,
Yasuaki Ishimatsu
On 01/24/2017 02:54 PM, Thomas Gleixner wrote:
On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote:
rapl_cpu_prepare() must be called after logical package id of CPU
is set
Hi Thomas,
Thank you for your review.
I'm not familiar with the component.
So I need your help to fix the issue.
Thanks,
Yasuaki Ishimatsu
On 01/24/2017 02:54 PM, Thomas Gleixner wrote:
On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote:
rapl_cpu_prepare() must be called after logical package id
Hi Thomas,
Thank you for your review.
I'm not familiar with the component.
So I need your help to fix the issue.
Thanks,
Yasuaki Ishimatsu
On 01/24/2017 02:54 PM, Thomas Gleixner wrote:
On Tue, 24 Jan 2017, Yasuaki Ishimatsu wrote:
rapl_cpu_prepare() must be called after logical package id
() is called
after topology_update_package_map().
Fixes: 9de8d686955b ("perf/x86/intel/rapl: Convert it to a per package
facility")
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
CC: Thomas Gleixner <t...@linutronix.de>
---
arch/x86/events/intel/rapl.c | 1
() is called
after topology_update_package_map().
Fixes: 9de8d686955b ("perf/x86/intel/rapl: Convert it to a per package
facility")
Signed-off-by: Yasuaki Ishimatsu
CC: Thomas Gleixner
---
arch/x86/events/intel/rapl.c | 11 ++-
include/linux/cpuhotplug.h | 2 +-
2 files
of changing
the memory zone from ZONE_NORMAL to ZONE_MOVABLE
Fixes: df429ac03936 ("memory-hotplug: more general validation of zone during
online")
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Reviewed-by: Reza Arbab <ar...@linux.vnet.ibm.com>
---
f
of changing
the memory zone from ZONE_NORMAL to ZONE_MOVABLE
Fixes: df429ac03936 ("memory-hotplug: more general validation of zone during
online")
Signed-off-by: Yasuaki Ishimatsu
Reviewed-by: Reza Arbab
---
from v2:
- Add the user-visible runtime effects of this fix
from v1:
-
Hi Andrew
On 01/09/2017 06:27 PM, Andrew Morton wrote:
On Tue, 13 Dec 2016 15:29:49 -0500 Yasuaki Ishimatsu <yasu.isim...@gmail.com>
wrote:
online_{kernel|movable} is used to change the memory zone to
ZONE_{NORMAL|MOVABLE} and online the memory.
To check that memory zone can be c
Hi Andrew
On 01/09/2017 06:27 PM, Andrew Morton wrote:
On Tue, 13 Dec 2016 15:29:49 -0500 Yasuaki Ishimatsu
wrote:
online_{kernel|movable} is used to change the memory zone to
ZONE_{NORMAL|MOVABLE} and online the memory.
To check that memory zone can be changed, zone_can_shift() is used
: Zhang Rui <rui.zh...@intel.com>
Cc: Eduardo Valentin <edubez...@gmail.com>
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jacob von Chorus <jacobvoncho...@cwphoto.ca>
Tested-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
Thanks,
Yasuaki
: Zhang Rui
Cc: Eduardo Valentin
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Jacob von Chorus
Tested-by: Yasuaki Ishimatsu
Thanks,
Yasuaki Ishimatsu
---
drivers/thermal/thermal_core.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
On 01/03/2017 11:45 PM, Zhang Rui wrote:
On Wed, 2017-01-04 at 12:35 +0800, Zhang Rui wrote:
On Thu, 2016-12-15 at 16:47 -0500, Yasuaki Ishimatsu wrote:
When offlining all cores on a CPU, the following system panic
occurs:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP
On 01/03/2017 11:45 PM, Zhang Rui wrote:
On Wed, 2017-01-04 at 12:35 +0800, Zhang Rui wrote:
On Thu, 2016-12-15 at 16:47 -0500, Yasuaki Ishimatsu wrote:
When offlining all cores on a CPU, the following system panic
occurs:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP
Here are two patches for memory hotplug:
Yasuaki Ishimatsu (2):
mm/sparse: use page_private() to get page->private value
mm/memory_hotplug: set magic number to page->freelsit instead
of page->lru.next
arch/x86/mm/init_64.c | 2 +-
mm/memory_hotplug.c | 5 +++--
mm
Here are two patches for memory hotplug:
Yasuaki Ishimatsu (2):
mm/sparse: use page_private() to get page->private value
mm/memory_hotplug: set magic number to page->freelsit instead
of page->lru.next
arch/x86/mm/init_64.c | 2 +-
mm/memory_hotplug.c | 5 +++--
mm
y occurs.
Until freeing the pages of page table allocated from bootmem allocator,
the page->freelist is never used. So the patch sets magic number to
page->freelist instead of page->lru.next.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
---
arch/x86/mm/init_64.c |
y occurs.
Until freeing the pages of page table allocated from bootmem allocator,
the page->freelist is never used. So the patch sets magic number to
page->freelist instead of page->lru.next.
Signed-off-by: Yasuaki Ishimatsu
---
arch/x86/mm/init_64.c | 2 +-
mm/memory_hotplug.c | 5 +++--
free_map_bootmem() uses page->private directly to set
removing_section_nr argument. But to get page->private
value, page_private() has been prepared.
So free_map_bootmem() should use page_private() instead of
page->private.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp
free_map_bootmem() uses page->private directly to set
removing_section_nr argument. But to get page->private
value, page_private() has been prepared.
So free_map_bootmem() should use page_private() instead of
page->private.
Signed-off-by: Yasuaki Ishimatsu
---
mm/sparse.c | 2 +
Here are two patches for memory hotplug:
Yasuaki Ishimatsu (2):
mm/sparse: use page_private() to get page->private value
mm/memory_hotplug: set magic number to page->freelsit instead
of page->lru.next
arch/x86/mm/init_64.c | 2 +-
mm/memory_hotplug.c | 4 ++--
mm
free_map_bootmem() uses page->private directly to set
removing_section_nr argument. But to get page->private
value, page_private() has been prepared.
So free_map_bootmem() should use page_private() instead of
page->private.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp
Here are two patches for memory hotplug:
Yasuaki Ishimatsu (2):
mm/sparse: use page_private() to get page->private value
mm/memory_hotplug: set magic number to page->freelsit instead
of page->lru.next
arch/x86/mm/init_64.c | 2 +-
mm/memory_hotplug.c | 4 ++--
mm
free_map_bootmem() uses page->private directly to set
removing_section_nr argument. But to get page->private
value, page_private() has been prepared.
So free_map_bootmem() should use page_private() instead of
page->private.
Signed-off-by: Yasuaki Ishimatsu
---
mm/sparse.c | 2 +
y occurs.
Until freeing the pages of page table allocated from bootmem allocator,
the page->freelist is never used. So the patch sets magic number to
page->freelist instead of page->lru.next.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
---
arch/x86/mm/init_64.c |
y occurs.
Until freeing the pages of page table allocated from bootmem allocator,
the page->freelist is never used. So the patch sets magic number to
page->freelist instead of page->lru.next.
Signed-off-by: Yasuaki Ishimatsu
---
arch/x86/mm/init_64.c | 2 +-
mm/memory_hotplug.c | 4 ++--
On 12/19/2016 11:21 PM, Eduardo Valentin wrote:
Hey Yasuaki San,
On Thu, Dec 15, 2016 at 04:47:08PM -0500, Yasuaki Ishimatsu wrote:
When offlining all cores on a CPU, the following system panic
occurs:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: strlen+0x0/0x20
Call
On 12/19/2016 11:21 PM, Eduardo Valentin wrote:
Hey Yasuaki San,
On Thu, Dec 15, 2016 at 04:47:08PM -0500, Yasuaki Ishimatsu wrote:
When offlining all cores on a CPU, the following system panic
occurs:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: strlen+0x0/0x20
Call
dds thermal_zone_remove_device_groups() to free
tz->device.groups and set NULL pointer.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasu...@jp.fujitsu.com>
CC: Zhang Rui <rui.zh...@intel.com>
CC: Eduardo Valentin <edubez...@gmail.com>
---
drivers/thermal/thermal_core.c | 3 ++-
drivers/the
dds thermal_zone_remove_device_groups() to free
tz->device.groups and set NULL pointer.
Signed-off-by: Yasuaki Ishimatsu
CC: Zhang Rui
CC: Eduardo Valentin
---
drivers/thermal/thermal_core.c | 3 ++-
drivers/thermal/thermal_core.h | 1 +
drivers/thermal/thermal_sysfs.c | 6 ++
3 files changed, 9 inse
1 - 100 of 1268 matches
Mail list logo
