* [PATCH 3/5] memory-hotplug: ia64: suitable memory should go to ZONE_MOVABLE
From: Wang Nan @ 2014-07-18 7:56 UTC (permalink / raw)
To: Ingo Molnar, Yinghai Lu, Mel Gorman, Andrew Morton
Cc: linux-ia64, Pei Feiyue, linux-sh, x86, linux-kernel, linux-mm,
linuxppc-dev
In-Reply-To: <1405670163-53747-1-git-send-email-wangnan0@huawei.com>
This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for ia64.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
---
arch/ia64/mm/init.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index 25c3502..d81c916 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -625,6 +625,7 @@ int arch_add_memory(int nid, u64 start, u64 size)
{
pg_data_t *pgdat;
struct zone *zone;
+ struct zone *movable_zone;
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
int ret;
@@ -632,6 +633,12 @@ int arch_add_memory(int nid, u64 start, u64 size)
pgdat = NODE_DATA(nid);
zone = pgdat->node_zones + ZONE_NORMAL;
+ movable_zone = pgdat->node_zones + ZONE_MOVABLE;
+ if (!zone_is_empty(movable_zone))
+ if (zone_spans_pfn(movable_zone, start_pfn) ||
+ (zone_end_pfn(movable_zone) <= start_pfn))
+ zone = movable_zone;
+
ret = __add_pages(nid, zone, start_pfn, nr_pages);
if (ret)
--
1.8.4
^ permalink raw reply related
* [PATCH 5/5] memory-hotplug: powerpc: suitable memory should go to ZONE_MOVABLE
From: Wang Nan @ 2014-07-18 7:56 UTC (permalink / raw)
To: Ingo Molnar, Yinghai Lu, Mel Gorman, Andrew Morton
Cc: linux-ia64, Pei Feiyue, linux-sh, x86, linux-kernel, linux-mm,
linuxppc-dev
In-Reply-To: <1405670163-53747-1-git-send-email-wangnan0@huawei.com>
This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for powerpc.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
---
arch/powerpc/mm/mem.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 2c8e90f..2d869ef 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -118,6 +118,7 @@ int arch_add_memory(int nid, u64 start, u64 size)
{
struct pglist_data *pgdata;
struct zone *zone;
+ struct zone *movable_zone;
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
@@ -129,6 +130,11 @@ int arch_add_memory(int nid, u64 start, u64 size)
/* this should work for most non-highmem platforms */
zone = pgdata->node_zones;
+ movable_zone = pgdat->node_zones + ZONE_MOVABLE;
+ if (!zone_is_empty(movable_zone))
+ if (zone_spans_pfn(movable_zone, start_pfn) ||
+ (zone_end_pfn(movable_zone) <= start_pfn))
+ zone = movable_zone;
return __add_pages(nid, zone, start_pfn, nr_pages);
}
--
1.8.4
^ permalink raw reply related
* Re: [RFC 1/2] workqueue: use the nearest NUMA node, not the local one
From: Lai Jiangshan @ 2014-07-18 8:11 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Fenghua Yu, Tony Luck, linux-ia64, linux-kernel, linux-mm,
David Rientjes, Tejun Heo, Joonsoo Kim, linuxppc-dev, Jiang Liu,
Wanpeng Li
In-Reply-To: <20140717230958.GB32660@linux.vnet.ibm.com>
Hi,
I'm curious about what will it happen when alloc_pages_node(memoryless_node).
If the memory is allocated from the most preferable node for the @memoryless_node,
why we need to bother and use cpu_to_mem() in the caller site?
If not, why the memory allocation subsystem refuses to find a preferable node
for @memoryless_node in this case? Does it intend on some purpose or
it can't find in some cases?
Thanks,
Lai
Added CC to Tejun (workqueue maintainer).
On 07/18/2014 07:09 AM, Nishanth Aravamudan wrote:
> In the presence of memoryless nodes, the workqueue code incorrectly uses
> cpu_to_node() to determine what node to prefer memory allocations come
> from. cpu_to_mem() should be used instead, which will use the nearest
> NUMA node with memory.
>
> Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 35974ac..0bba022 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -3547,7 +3547,12 @@ static struct worker_pool *get_unbound_pool(const struct workqueue_attrs *attrs)
> for_each_node(node) {
> if (cpumask_subset(pool->attrs->cpumask,
> wq_numa_possible_cpumask[node])) {
> - pool->node = node;
> + /*
> + * We could use local_memory_node(node) here,
> + * but it is expensive and the following caches
> + * the same value.
> + */
> + pool->node = cpu_to_mem(cpumask_first(pool->attrs->cpumask));
> break;
> }
> }
> @@ -4921,7 +4926,7 @@ static int __init init_workqueues(void)
> pool->cpu = cpu;
> cpumask_copy(pool->attrs->cpumask, cpumask_of(cpu));
> pool->attrs->nice = std_nice[i++];
> - pool->node = cpu_to_node(cpu);
> + pool->node = cpu_to_mem(cpu);
>
> /* alloc pool ID */
> mutex_lock(&wq_pool_mutex);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH 4/5] memory-hotplug: sh: suitable memory should go to ZONE_MOVABLE
From: Wang Nan @ 2014-07-18 7:56 UTC (permalink / raw)
To: Ingo Molnar, Yinghai Lu, Mel Gorman, Andrew Morton
Cc: linux-ia64, Pei Feiyue, linux-sh, x86, linux-kernel, linux-mm,
linuxppc-dev
In-Reply-To: <1405670163-53747-1-git-send-email-wangnan0@huawei.com>
This patch add new memory to ZONE_MOVABLE if movable zone is setup
and lower than newly added memory for sh.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
---
arch/sh/mm/init.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c
index 2d089fe..ff9decc 100644
--- a/arch/sh/mm/init.c
+++ b/arch/sh/mm/init.c
@@ -487,16 +487,19 @@ void free_initrd_mem(unsigned long start, unsigned long end)
#ifdef CONFIG_MEMORY_HOTPLUG
int arch_add_memory(int nid, u64 start, u64 size)
{
- pg_data_t *pgdat;
+ pg_data_t *pgdat = NODE_DATA(nid);
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
+ struct zone *zone = pgdat->node_zones + ZONE_NORMAL;
+ struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
int ret;
- pgdat = NODE_DATA(nid);
+ if (!zone_is_empty(movable_zone))
+ if (zone_spans_pfn(movable_zone, start_pfn) ||
+ (zone_end_pfn(movable_zone) <= start_pfn))
+ zone = movable_zone;
- /* We only have ZONE_NORMAL, so this is easy.. */
- ret = __add_pages(nid, pgdat->node_zones + ZONE_NORMAL,
- start_pfn, nr_pages);
+ ret = __add_pages(nid, zone, start_pfn, nr_pages);
if (unlikely(ret))
printk("%s: Failed, __add_pages() == %d\n", __func__, ret);
--
1.8.4
^ permalink raw reply related
* RE: [PATCH v5 4/5] KVM: PPC: Alow kvmppc_get_last_inst() to fail
From: mihai.caraman @ 2014-07-18 9:05 UTC (permalink / raw)
To: Alexander Graf, kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org
In-Reply-To: <53C7DBC3.2060104@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, July 17, 2014 5:21 PM
> To: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org
> Cc: kvm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v5 4/5] KVM: PPC: Alow kvmppc_get_last_inst() to fail
>=20
>=20
> On 17.07.14 13:22, Mihai Caraman wrote:
> > On book3e, guest last instruction is read on the exit path using load
> > external pid (lwepx) dedicated instruction. This load operation may
> fail
> > due to TLB eviction and execute-but-not-read entries.
> >
> > This patch lay down the path for an alternative solution to read the
> guest
> > last instruction, by allowing kvmppc_get_lat_inst() function to fail.
> > Architecture specific implmentations of kvmppc_load_last_inst() may
> read
> > last guest instruction and instruct the emulation layer to re-execute
> the
> > guest in case of failure.
> >
> > Make kvmppc_get_last_inst() definition common between architectures.
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> > ---
...
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> > index e2fd5a1..7f9c634 100644
> > --- a/arch/powerpc/include/asm/kvm_ppc.h
> > +++ b/arch/powerpc/include/asm/kvm_ppc.h
> > @@ -47,6 +47,11 @@ enum emulation_result {
> > EMULATE_EXIT_USER, /* emulation requires exit to user-space */
> > };
> >
> > +enum instruction_type {
> > + INST_GENERIC,
> > + INST_SC, /* system call */
> > +};
> > +
> > extern int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu
> *vcpu);
> > extern int __kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu
> *vcpu);
> > extern void kvmppc_handler_highmem(void);
> > @@ -62,6 +67,9 @@ extern int kvmppc_handle_store(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> > u64 val, unsigned int bytes,
> > int is_default_endian);
> >
> > +extern int kvmppc_load_last_inst(struct kvm_vcpu *vcpu,
> > + enum instruction_type type, u32 *inst);
> > +
> > extern int kvmppc_emulate_instruction(struct kvm_run *run,
> > struct kvm_vcpu *vcpu);
> > extern int kvmppc_emulate_mmio(struct kvm_run *run, struct kvm_vcpu
> *vcpu);
> > @@ -234,6 +242,23 @@ struct kvmppc_ops {
> > extern struct kvmppc_ops *kvmppc_hv_ops;
> > extern struct kvmppc_ops *kvmppc_pr_ops;
> >
> > +static inline int kvmppc_get_last_inst(struct kvm_vcpu *vcpu,
> > + enum instruction_type type, u32 *inst)
> > +{
> > + int ret =3D EMULATE_DONE;
> > +
> > + /* Load the instruction manually if it failed to do so in the
> > + * exit path */
> > + if (vcpu->arch.last_inst =3D=3D KVM_INST_FETCH_FAILED)
> > + ret =3D kvmppc_load_last_inst(vcpu, type, &vcpu-
> >arch.last_inst);
> > +
> > +
> > + *inst =3D (ret =3D=3D EMULATE_DONE && kvmppc_need_byteswap(vcpu)) ?
> > + swab32(vcpu->arch.last_inst) : vcpu->arch.last_inst;
>=20
> This makes even less sense than the previous version. Either you treat
> inst as "definitely overwritten" or as "preserves previous data on
> failure".
Both v4 and v5 versions treat inst as "definitely overwritten".
>=20
> So either you unconditionally swap like you did before
If we make abstraction of its symmetry, KVM_INST_FETCH_FAILED is operated
in host endianness, so it doesn't need byte swap.
I agree with your reasoning if last_inst is initialized and compared with
data in guest endianess, which is not the case yet for KVM_INST_FETCH_FAILE=
D.
> or you do
>=20
> if (ret =3D=3D EMULATE_DONE)
> *inst =3D kvmppc_need_byteswap(vcpu) ? swab32(vcpu->arch.last_inst) =
:
> vcpu->arch.last_inst;
-Mike
^ permalink raw reply
* Re: [PATCH 0/5] memory-hotplug: suitable memory should go to ZONE_MOVABLE
From: Zhang Yanfei @ 2014-07-18 9:16 UTC (permalink / raw)
To: Wang Nan
Cc: linux-ia64, Pei Feiyue, linux-sh, linuxppc-dev, x86, linux-kernel,
linux-mm, Ingo Molnar, Mel Gorman, Andrew Morton, Yinghai Lu
In-Reply-To: <1405670163-53747-1-git-send-email-wangnan0@huawei.com>
Hello,
On 07/18/2014 03:55 PM, Wang Nan wrote:
> This series of patches fix a problem when adding memory in bad manner.
> For example: for a x86_64 machine booted with "mem=400M" and with 2GiB
> memory installed, following commands cause problem:
>
> # echo 0x40000000 > /sys/devices/system/memory/probe
> [ 28.613895] init_memory_mapping: [mem 0x40000000-0x47ffffff]
> # echo 0x48000000 > /sys/devices/system/memory/probe
> [ 28.693675] init_memory_mapping: [mem 0x48000000-0x4fffffff]
> # echo online_movable > /sys/devices/system/memory/memory9/state
> # echo 0x50000000 > /sys/devices/system/memory/probe
> [ 29.084090] init_memory_mapping: [mem 0x50000000-0x57ffffff]
> # echo 0x58000000 > /sys/devices/system/memory/probe
> [ 29.151880] init_memory_mapping: [mem 0x58000000-0x5fffffff]
> # echo online_movable > /sys/devices/system/memory/memory11/state
> # echo online> /sys/devices/system/memory/memory8/state
> # echo online> /sys/devices/system/memory/memory10/state
> # echo offline> /sys/devices/system/memory/memory9/state
> [ 30.558819] Offlined Pages 32768
> # free
> total used free shared buffers cached
> Mem: 780588 18014398509432020 830552 0 0 51180
> -/+ buffers/cache: 18014398509380840 881732
> Swap: 0 0 0
>
> This is because the above commands probe higher memory after online a
> section with online_movable, which causes ZONE_HIGHMEM (or ZONE_NORMAL
> for systems without ZONE_HIGHMEM) overlaps ZONE_MOVABLE.
Yeah, this is rare in reality but can happen. Could you please also
include the free result and zoneinfo after applying your patch?
Thanks.
>
> After the second online_movable, the problem can be observed from
> zoneinfo:
>
> # cat /proc/zoneinfo
> ...
> Node 0, zone Movable
> pages free 65491
> min 250
> low 312
> high 375
> scanned 0
> spanned 18446744073709518848
> present 65536
> managed 65536
> ...
>
> This series of patches solve the problem by checking ZONE_MOVABLE when
> choosing zone for new memory. If new memory is inside or higher than
> ZONE_MOVABLE, makes it go there instead.
>
>
> Wang Nan (5):
> memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE
> memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE
> memory-hotplug: ia64: suitable memory should go to ZONE_MOVABLE
> memory-hotplug: sh: suitable memory should go to ZONE_MOVABLE
> memory-hotplug: powerpc: suitable memory should go to ZONE_MOVABLE
>
> arch/ia64/mm/init.c | 7 +++++++
> arch/powerpc/mm/mem.c | 6 ++++++
> arch/sh/mm/init.c | 13 ++++++++-----
> arch/x86/mm/init_32.c | 6 ++++++
> arch/x86/mm/init_64.c | 10 ++++++++--
> 5 files changed, 35 insertions(+), 7 deletions(-)
>
--
Thanks.
Zhang Yanfei
^ permalink raw reply
* Re: [PATCH 2/5] memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE
From: Wang Nan @ 2014-07-18 9:52 UTC (permalink / raw)
To: Ingo Molnar, Yinghai Lu, Mel Gorman, Andrew Morton
Cc: linux-ia64, Pei Feiyue, linux-sh, x86, linux-kernel, linux-mm,
linuxppc-dev
In-Reply-To: <1405670163-53747-3-git-send-email-wangnan0@huawei.com>
On 2014/7/18 15:56, Wang Nan wrote:
> This patch add new memory to ZONE_MOVABLE if movable zone is setup
> and lower than newly added memory for x86_32.
>
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> ---
> arch/x86/mm/init_32.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index e395048..dd69833 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -826,9 +826,15 @@ int arch_add_memory(int nid, u64 start, u64 size)
> {
> struct pglist_data *pgdata = NODE_DATA(nid);
> struct zone *zone = pgdata->node_zones + ZONE_HIGHMEM;
> + struct zone *movable_zone = pgdat->node_zones + ZONE_MOVABLE;
Sorry. pgdat should be pgdata.
> unsigned long start_pfn = start >> PAGE_SHIFT;
> unsigned long nr_pages = size >> PAGE_SHIFT;
>
> + if (!zone_is_empty(movable_zone))
> + if (zone_spans_pfn(movable_zone, start_pfn) ||
> + (zone_end_pfn(movable_zone) <= start_pfn))
> + zone = movable_zone;
> +
> return __add_pages(nid, zone, start_pfn, nr_pages);
> }
>
>
^ permalink raw reply
* Re: [PATCH 0/5] memory-hotplug: suitable memory should go to ZONE_MOVABLE
From: Wang Nan @ 2014-07-18 9:56 UTC (permalink / raw)
To: Zhang Yanfei
Cc: linux-ia64, Pei Feiyue, linux-sh, linuxppc-dev, x86, linux-kernel,
linux-mm, Ingo Molnar, Mel Gorman, Andrew Morton, Yinghai Lu
In-Reply-To: <53C8E602.1060301@cn.fujitsu.com>
On 2014/7/18 17:16, Zhang Yanfei wrote:
> Hello,
>
> On 07/18/2014 03:55 PM, Wang Nan wrote:
>> This series of patches fix a problem when adding memory in bad manner.
>> For example: for a x86_64 machine booted with "mem=400M" and with 2GiB
>> memory installed, following commands cause problem:
>>
>> # echo 0x40000000 > /sys/devices/system/memory/probe
>> [ 28.613895] init_memory_mapping: [mem 0x40000000-0x47ffffff]
>> # echo 0x48000000 > /sys/devices/system/memory/probe
>> [ 28.693675] init_memory_mapping: [mem 0x48000000-0x4fffffff]
>> # echo online_movable > /sys/devices/system/memory/memory9/state
>> # echo 0x50000000 > /sys/devices/system/memory/probe
>> [ 29.084090] init_memory_mapping: [mem 0x50000000-0x57ffffff]
>> # echo 0x58000000 > /sys/devices/system/memory/probe
>> [ 29.151880] init_memory_mapping: [mem 0x58000000-0x5fffffff]
>> # echo online_movable > /sys/devices/system/memory/memory11/state
>> # echo online> /sys/devices/system/memory/memory8/state
>> # echo online> /sys/devices/system/memory/memory10/state
>> # echo offline> /sys/devices/system/memory/memory9/state
>> [ 30.558819] Offlined Pages 32768
>> # free
>> total used free shared buffers cached
>> Mem: 780588 18014398509432020 830552 0 0 51180
>> -/+ buffers/cache: 18014398509380840 881732
>> Swap: 0 0 0
>>
>> This is because the above commands probe higher memory after online a
>> section with online_movable, which causes ZONE_HIGHMEM (or ZONE_NORMAL
>> for systems without ZONE_HIGHMEM) overlaps ZONE_MOVABLE.
>
> Yeah, this is rare in reality but can happen. Could you please also
> include the free result and zoneinfo after applying your patch?
>
> Thanks.
>
OK.
I paste the free result and zoneinfo at the end of this mail. This is a x86_64 result,
generated on qemu, after applying my patches.
I only tested x86_64 and x86_32 (and found a typo). Could any one can help me verify
other platforms?
Thanks.
>>
>> After the second online_movable, the problem can be observed from
>> zoneinfo:
>>
>> # cat /proc/zoneinfo
>> ...
>> Node 0, zone Movable
>> pages free 65491
>> min 250
>> low 312
>> high 375
>> scanned 0
>> spanned 18446744073709518848
>> present 65536
>> managed 65536
>> ...
>>
>> This series of patches solve the problem by checking ZONE_MOVABLE when
>> choosing zone for new memory. If new memory is inside or higher than
>> ZONE_MOVABLE, makes it go there instead.
>>
>>
>> Wang Nan (5):
>> memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE
>> memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE
>> memory-hotplug: ia64: suitable memory should go to ZONE_MOVABLE
>> memory-hotplug: sh: suitable memory should go to ZONE_MOVABLE
>> memory-hotplug: powerpc: suitable memory should go to ZONE_MOVABLE
>>
>> arch/ia64/mm/init.c | 7 +++++++
>> arch/powerpc/mm/mem.c | 6 ++++++
>> arch/sh/mm/init.c | 13 ++++++++-----
>> arch/x86/mm/init_32.c | 6 ++++++
>> arch/x86/mm/init_64.c | 10 ++++++++--
>> 5 files changed, 35 insertions(+), 7 deletions(-)
>>
>
>
After applying the above patches, here is the free result and zoneinfo (after offline memory9):
bash-4.2# free
total used free shared buffers cached
Mem: 780588 80860 699728 0 0 51180
-/+ buffers/cache: 29680 750908
Swap: 0 0 0
bash-4.2# cat /proc/zoneinfo
Node 0, zone DMA
pages free 3272
min 14
low 17
high 21
scanned 0
spanned 4095
present 3998
managed 3977
nr_free_pages 3272
...
start_pfn: 1
inactive_ratio: 1
Node 0, zone DMA32
pages free 73548
min 341
low 426
high 511
scanned 0
spanned 98304
present 98304
managed 92866
nr_free_pages 73548
...
start_pfn: 4096
inactive_ratio: 1
Node 0, zone Normal
pages free 32630
min 120
low 150
high 180
scanned 0
spanned 32768
present 32768
managed 32768
nr_free_pages 32630
...
start_pfn: 262144
inactive_ratio: 1
Node 0, zone Movable
pages free 65491
min 241
low 301
high 361
scanned 0
spanned 98304
present 65536
managed 65536
nr_free_pages 65491
...
start_pfn: 294912
inactive_ratio: 1
^ permalink raw reply
* Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area
From: Will Deacon @ 2014-07-18 10:14 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Catalin Marinas, Heiko Carstens, linux-mm@kvack.org,
Paul Mackerras, H. Peter Anvin, linux-arch,
linux-s390@vger.kernel.org, Richard Weinberger, X86 ML,
Ingo Molnar, Fenghua Yu,
user-mode-linux-devel@lists.sourceforge.net, Jeff Dike,
Chris Metcalf, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Tony Luck, Nathan Lynch,
linux-kernel@vger.kernel.org, Martin Schwidefsky,
linux390@de.ibm.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CALCETrXG6nL4K=Er+kv5-CXBDVa0TLg9yR6iePnMyE2ufXgKkw@mail.gmail.com>
On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > The core mm code will provide a default gate area based on
> > FIXADDR_USER_START and FIXADDR_USER_END if
> > !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
> >
> > This default is only useful for ia64. arm64, ppc, s390, sh, tile,
> > 64-bit UML, and x86_32 have their own code just to disable it. arm,
> > 32-bit UML, and x86_64 have gate areas, but they have their own
> > implementations.
> >
> > This gets rid of the default and moves the code into ia64.
> >
> > This should save some code on architectures without a gate area: it's
> > now possible to inline the gate_area functions in the default case.
>
> Can one of you pull this somewhere? Otherwise I can put it somewhere
> stable and ask for -next inclusion, but that seems like overkill for a
> single patch.
I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
changes (or changes to other archs) to go via our tree.
I'm not sure what the best approach is if you want to send this via a single
tree. Maybe you could ask akpm nicely?
Will
^ permalink raw reply
* [PATCH] powerpc : dma-mapping : Check null condition for dev->archdata.dma_ops
From: Nikhil Badola @ 2014-07-18 10:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nikhil Badola
Modifies get_dma_ops() implementation on ppc arch to check null condition
for dev->archdata.dma_ops; returns common dma_direct_ops structure in
case its NULL
Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
---
arch/powerpc/include/asm/dma-mapping.h | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 150866b..d73bae8 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -86,10 +86,12 @@ static inline struct dma_map_ops *get_dma_ops(struct device *dev)
*/
if (unlikely(dev == NULL))
return NULL;
-
- return dev->archdata.dma_ops;
+ if (dev->archdata.dma_ops)
+ return dev->archdata.dma_ops;
+ return &dma_direct_ops;
}
+
static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
{
dev->archdata.dma_ops = ops;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH 1/2] ASoC: fsl_sai: Reset FIFOs after disabling TE/RE
From: Nicolin Chen @ 2014-07-18 10:18 UTC (permalink / raw)
To: Nicolin Chen
Cc: alsa-devel, broonie, b42378, b02247, linux-kernel, timur,
Li.Xiubo, linuxppc-dev
In-Reply-To: <9ef07dc9cc98b19e3f81f8374617605bf0d9faeb.1405603108.git.nicoleotsuka@gmail.com>
Mark,
Please disregard this single patch.
On Thu, Jul 17, 2014 at 09:21:37PM +0800, Nicolin Chen wrote:
> SAI will not clear their FIFOs after disabling TE/RE. Therfore, the driver
> should take care the task so as not to let useless data remain in the FIFO.
>
> Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
> ---
> sound/soc/fsl/fsl_sai.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
> index c5a0e8a..b10dbd8 100644
> --- a/sound/soc/fsl/fsl_sai.c
> +++ b/sound/soc/fsl/fsl_sai.c
> @@ -371,10 +371,13 @@ static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
>
> /* Check if the opposite FRDE is also disabled */
> if (!(tx ? rcsr & FSL_SAI_CSR_FRDE : tcsr & FSL_SAI_CSR_FRDE)) {
> + /* Disable both directions and reset their FIFOs */
> regmap_update_bits(sai->regmap, FSL_SAI_TCSR,
> - FSL_SAI_CSR_TERE, 0);
> + FSL_SAI_CSR_TERE | FSL_SAI_CSR_FR,
> + FSL_SAI_CSR_FR);
> regmap_update_bits(sai->regmap, FSL_SAI_RCSR,
> - FSL_SAI_CSR_TERE, 0);
> + FSL_SAI_CSR_TERE | FSL_SAI_CSR_FR,
> + FSL_SAI_CSR_FR);
The FR should be set _after_ clear TERE, not at the same time because it
still may have tiny possibility to remain data.
I'll send another version later for this patch.
The other patch for isr() should be still fine.
Thank you,
Nicolin
> }
> break;
> default:
> --
> 1.8.4
>
^ permalink raw reply
* Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area
From: Richard Weinberger @ 2014-07-18 10:20 UTC (permalink / raw)
To: Will Deacon, Andy Lutomirski
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Catalin Marinas, Heiko Carstens, linux-mm@kvack.org,
Paul Mackerras, H. Peter Anvin, linux-arch,
linux-s390@vger.kernel.org, X86 ML, Ingo Molnar, Fenghua Yu,
user-mode-linux-devel@lists.sourceforge.net, Jeff Dike,
Chris Metcalf, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Tony Luck, Nathan Lynch,
linux-kernel@vger.kernel.org, Martin Schwidefsky,
linux390@de.ibm.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140718101416.GB1818@arm.com>
Am 18.07.2014 12:14, schrieb Will Deacon:
> On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
>> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>> The core mm code will provide a default gate area based on
>>> FIXADDR_USER_START and FIXADDR_USER_END if
>>> !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
>>>
>>> This default is only useful for ia64. arm64, ppc, s390, sh, tile,
>>> 64-bit UML, and x86_32 have their own code just to disable it. arm,
>>> 32-bit UML, and x86_64 have gate areas, but they have their own
>>> implementations.
>>>
>>> This gets rid of the default and moves the code into ia64.
>>>
>>> This should save some code on architectures without a gate area: it's
>>> now possible to inline the gate_area functions in the default case.
>>
>> Can one of you pull this somewhere? Otherwise I can put it somewhere
>> stable and ask for -next inclusion, but that seems like overkill for a
>> single patch.
For the um bits:
Acked-by: Richard Weinberger <richard@nod.at>
> I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
> changes (or changes to other archs) to go via our tree.
>
> I'm not sure what the best approach is if you want to send this via a single
> tree. Maybe you could ask akpm nicely?
Going though Andrew's tree sounds sane to me.
Thanks,
//richard
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Tejun Heo @ 2014-07-18 11:20 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Fenghua Yu, Tony Luck, linux-ia64, linux-kernel, linux-mm,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <20140717230923.GA32660@linux.vnet.ibm.com>
On Thu, Jul 17, 2014 at 04:09:23PM -0700, Nishanth Aravamudan wrote:
> [Apologies for the large Cc list, but I believe we have the following
> interested parties:
>
> x86 (recently posted memoryless node support)
> ia64 (existing memoryless node support)
> ppc (existing memoryless node support)
> previous discussion of how to solve Anton's issue with slab usage
> workqueue contributors/maintainers]
Well, you forgot to cc me.
...
> It turns out we see this large slab usage due to using the wrong NUMA
> information when creating kthreads.
>
> Two changes are required, one of which is in the workqueue code and one
> of which is in the powerpc initialization. Note that ia64 may want to
> consider something similar.
Wasn't there a thread on this exact subject a few weeks ago? Was that
someone else? Memory-less node detail leaking out of allocator proper
isn't a good idea. Please allow allocator users to specify the nodes
they're on and let the allocator layer deal with mapping that to
whatever is appropriate. Please don't push that to everybody.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] powerpc : dma-mapping : Check null condition for dev->archdata.dma_ops
From: Denis Kirjanov @ 2014-07-18 13:51 UTC (permalink / raw)
To: Nikhil Badola; +Cc: linuxppc-dev
In-Reply-To: <1405677892-7201-1-git-send-email-nikhil.badola@freescale.com>
On 7/18/14, Nikhil Badola <nikhil.badola@freescale.com> wrote:
> Modifies get_dma_ops() implementation on ppc arch to check null condition
which means that dma is not supported.
Could you please describe the use case where the ops is null.
> for dev->archdata.dma_ops; returns common dma_direct_ops structure in
> case its NULL
>
> Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
> ---
> arch/powerpc/include/asm/dma-mapping.h | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h
> b/arch/powerpc/include/asm/dma-mapping.h
> index 150866b..d73bae8 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -86,10 +86,12 @@ static inline struct dma_map_ops *get_dma_ops(struct
> device *dev)
> */
> if (unlikely(dev == NULL))
> return NULL;
> -
> - return dev->archdata.dma_ops;
> + if (dev->archdata.dma_ops)
> + return dev->archdata.dma_ops;
> + return &dma_direct_ops;
> }
>
> +
> static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
> {
> dev->archdata.dma_ops = ops;
> --
> 1.7.11.7
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Regards,
Denis
^ permalink raw reply
* Re: [PATCH 1/5] memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE
From: Dave Hansen @ 2014-07-18 15:00 UTC (permalink / raw)
To: Wang Nan, Ingo Molnar, Yinghai Lu, Mel Gorman, Andrew Morton
Cc: linux-ia64, Pei Feiyue, linux-sh, x86, linux-kernel, linux-mm,
linuxppc-dev
In-Reply-To: <1405670163-53747-2-git-send-email-wangnan0@huawei.com>
On 07/18/2014 12:55 AM, Wang Nan wrote:
> + if (!zone_is_empty(movable_zone))
> + if (zone_spans_pfn(movable_zone, start_pfn) ||
> + (zone_end_pfn(movable_zone) <= start_pfn))
> + zone = movable_zone;
> +
It's nice that you hit so many architectures, but is there a way to do
this that doesn't involve copying and pasting the same bit of code in to
each architecture?
^ permalink raw reply
* Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area
From: Andy Lutomirski @ 2014-07-18 16:53 UTC (permalink / raw)
To: Richard Weinberger, Andrew Morton
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Catalin Marinas, Heiko Carstens, linux-mm@kvack.org,
Paul Mackerras, H. Peter Anvin, linux-arch,
linux-s390@vger.kernel.org, X86 ML, Ingo Molnar, Fenghua Yu,
user-mode-linux-devel@lists.sourceforge.net, Will Deacon,
Jeff Dike, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Tony Luck, Nathan Lynch,
linux-kernel@vger.kernel.org, Martin Schwidefsky,
linux390@de.ibm.com, linuxppc-dev
In-Reply-To: <53C8F4DF.8020103@nod.at>
[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]
On Jul 18, 2014 3:20 AM, "Richard Weinberger" <richard@nod.at> wrote:
>
> Am 18.07.2014 12:14, schrieb Will Deacon:
> > On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
> >> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski <luto@amacapital.net>
wrote:
> >>> The core mm code will provide a default gate area based on
> >>> FIXADDR_USER_START and FIXADDR_USER_END if
> >>> !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
> >>>
> >>> This default is only useful for ia64. arm64, ppc, s390, sh, tile,
> >>> 64-bit UML, and x86_32 have their own code just to disable it. arm,
> >>> 32-bit UML, and x86_64 have gate areas, but they have their own
> >>> implementations.
> >>>
> >>> This gets rid of the default and moves the code into ia64.
> >>>
> >>> This should save some code on architectures without a gate area: it's
> >>> now possible to inline the gate_area functions in the default case.
> >>
> >> Can one of you pull this somewhere? Otherwise I can put it somewhere
> >> stable and ask for -next inclusion, but that seems like overkill for a
> >> single patch.
>
> For the um bits:
> Acked-by: Richard Weinberger <richard@nod.at>
>
> > I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
> > changes (or changes to other archs) to go via our tree.
> >
> > I'm not sure what the best approach is if you want to send this via a
single
> > tree. Maybe you could ask akpm nicely?
>
> Going though Andrew's tree sounds sane to me.
Splitting this will be annoying: I'd probably have to add a flag asking for
the new behavior, update all the arches, then remove the flag. The chance
of screwing up bisectability in the process seems pretty high. This seems
like overkill for a patch that mostly deletes code.
Akpm, can you take this?
--Andy
>
> Thanks,
> //richard
[-- Attachment #2: Type: text/html, Size: 2616 bytes --]
^ permalink raw reply
* Re: [RFC 1/2] workqueue: use the nearest NUMA node, not the local one
From: Nish Aravamudan @ 2014-07-18 17:33 UTC (permalink / raw)
To: Lai Jiangshan
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Tejun Heo, Joonsoo Kim, linuxppc-dev, Jiang Liu,
Wanpeng Li
In-Reply-To: <53C8D6A8.3040400@cn.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 5911 bytes --]
[ Apologies for replying from a different address, we have a service outage
at work. ]
On Fri, Jul 18, 2014 at 1:11 AM, Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
>
> Hi,
Thank you for your response!
> I'm curious about what will it happen when
alloc_pages_node(memoryless_node).
alloc_pages_node() is only involved in one of the possible paths (maybe
this occurs on x86 with THREAD_INFO > PAGE_SIZE?) On powerpc, though,
that's not the case.
Details:
1. pool->node is used in the invocation of kthread_create_on_node() in
create_worker().
2. kthread_create_on_node sets up a struct kthread_create_info with
create->node = node and wakes up kthreadd.
3. kthreadd calls create_kthread, which sets current->pref_node_fork =
create->node.
4. dup_task_struct() calls node = tsk_fork_get_node() before invoking
alloc_task_struct_node(node) and alloc_thread_info_node(node).
5. tsk_fork_get_node() returns current->pref_node_fork for kthreadd.
6. alloc_task_struct_node() calls kmem_cache_alloc_node(,GFP_KERNEL, node)
7. alloc_thread_info_node() either calls kmem_cache_alloc_node(,GFP_KERNEL,
node) or alloc_kmem_pages_node(node,GFP_KERNEL,), depending on the size of
THREAD_INFO relative to PAGE_SIZE.
8a. alloc_kmem_pages_node() -> alloc_pages_node -> __alloc_pages with a
zonelist built from node_zonelist. This should lead to proper fallback.
8b. kmem_cache_alloc_node() calls slab_alloc_node()
9. For a memoryless node, we will trigger the following:
if (unlikely(!object || !node_match(page, node))) {
object = __slab_alloc(s, gfpflags, node, addr, c);
stat(s, ALLOC_SLOWPATH);
}
10. __slab_alloc() in turn will:
if (unlikely(!node_match(page, node))) {
stat(s, ALLOC_NODE_MISMATCH);
deactivate_slab(s, page, c->freelist);
c->page = NULL;
c->freelist = NULL;
goto new_slab;
}
deactivating the slab. Thus, every kthread created with a node
specification leads to a single object on a slab. We see an explosion in
the slab consumption, all of which is unreclaimable.
Anton originally proposed not deactivating slabs when we *know* the
allocation will be remote (i.e., from a memoryless node). Joonsoo and
Christoph disagreed with this and proposed alternative solutions, which
weren't agreed upon at the time.
> If the memory is allocated from the most preferable node for the
@memoryless_node,
> why we need to bother and use cpu_to_mem() in the caller site?
The reason is that the node passed is a hint into the MM subsystem of what
node we want memory to come from. Well, I take that back, I think
semantically there are two ways to interpret the node parameter:
1) The NUMA node we want memory from
2) The NUMA node we expect memory from
The path through the MM above sort of conflates the two, the caller
specified an impossible request (which the MM subsystem technically knows
but which knowledge it isn't using at this point) of memory from a node
that has none.
We could change the core MM to do better in the presence of memoryless
nodes, and should, but this seems far less invasive and does the right
thing. Semantically, I think the workqueue's pool->node is meant to be the
node from which we want memory allocated, which is the node with memory
closest to the CPU.
Thanks,
Nish
> If not, why the memory allocation subsystem refuses to find a preferable
node
> for @memoryless_node in this case? Does it intend on some purpose or
> it can't find in some cases?
>
> Thanks,
> Lai
>
> Added CC to Tejun (workqueue maintainer).
>
> On 07/18/2014 07:09 AM, Nishanth Aravamudan wrote:
> > In the presence of memoryless nodes, the workqueue code incorrectly uses
> > cpu_to_node() to determine what node to prefer memory allocations come
> > from. cpu_to_mem() should be used instead, which will use the nearest
> > NUMA node with memory.
> >
> > Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
> >
> > diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> > index 35974ac..0bba022 100644
> > --- a/kernel/workqueue.c
> > +++ b/kernel/workqueue.c
> > @@ -3547,7 +3547,12 @@ static struct worker_pool
*get_unbound_pool(const struct workqueue_attrs *attrs)
> > for_each_node(node) {
> > if (cpumask_subset(pool->attrs->cpumask,
> >
wq_numa_possible_cpumask[node])) {
> > - pool->node = node;
> > + /*
> > + * We could use local_memory_node(node)
here,
> > + * but it is expensive and the following
caches
> > + * the same value.
> > + */
> > + pool->node =
cpu_to_mem(cpumask_first(pool->attrs->cpumask));
> > break;
> > }
> > }
> > @@ -4921,7 +4926,7 @@ static int __init init_workqueues(void)
> > pool->cpu = cpu;
> > cpumask_copy(pool->attrs->cpumask,
cpumask_of(cpu));
> > pool->attrs->nice = std_nice[i++];
> > - pool->node = cpu_to_node(cpu);
> > + pool->node = cpu_to_mem(cpu);
> >
> > /* alloc pool ID */
> > mutex_lock(&wq_pool_mutex);
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
[-- Attachment #2: Type: text/html, Size: 7835 bytes --]
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Nish Aravamudan @ 2014-07-18 17:42 UTC (permalink / raw)
To: Tejun Heo
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <20140718112039.GA8383@htj.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]
Hi Tejun,
On Fri, Jul 18, 2014 at 4:20 AM, Tejun Heo <tj@kernel.org> wrote:
>
> On Thu, Jul 17, 2014 at 04:09:23PM -0700, Nishanth Aravamudan wrote:
> > [Apologies for the large Cc list, but I believe we have the following
> > interested parties:
> >
> > x86 (recently posted memoryless node support)
> > ia64 (existing memoryless node support)
> > ppc (existing memoryless node support)
> > previous discussion of how to solve Anton's issue with slab usage
> > workqueue contributors/maintainers]
>
> Well, you forgot to cc me.
Ah I'm very sorry! That's what I get for editing e-mails... Thank you for
your reply!
> ...
> > It turns out we see this large slab usage due to using the wrong NUMA
> > information when creating kthreads.
> >
> > Two changes are required, one of which is in the workqueue code and one
> > of which is in the powerpc initialization. Note that ia64 may want to
> > consider something similar.
>
> Wasn't there a thread on this exact subject a few weeks ago? Was that
> someone else? Memory-less node detail leaking out of allocator proper
> isn't a good idea. Please allow allocator users to specify the nodes
> they're on and let the allocator layer deal with mapping that to
> whatever is appropriate. Please don't push that to everybody.
I didn't send anything for the workqueue logic anytime recently. Jiang sent
out a patchset for x86 memoryless node support, which may have touched
kernel/workqueue.c.
So, to be clear, this is not *necessarily* about memoryless nodes. It's
about the semantics intended. The workqueue code currently calls
cpu_to_node() in a few places, and passes that node into the core MM as a
hint about where the memory should come from. However, when memoryless
nodes are present, that hint is guaranteed to be wrong, as it's the nearest
NUMA node to the CPU (which happens to be the one its on), not the nearest
NUMA node with memory. The hint is correctly specified as cpu_to_mem(),
which does the right thing in the presence or absence of memoryless nodes.
And I think encapsulates the hint's semantics correctly -- please give me
memory from where I expect it, which is the closest NUMA node.
I guess we could also change tsk_fork_get_node to return
local_memory_node(tsk->pref_node_fork), but that can be a bit expensive, as
it generates a new zonelist each time to determine the first fallback node.
We get the exact same semantics (because cpu_to_mem() caches the result of
local_memory_node) by using cpu_to_mem directly.
Again, apologies for not Cc'ing you originally.
-Nish
[-- Attachment #2: Type: text/html, Size: 2947 bytes --]
^ permalink raw reply
* Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area
From: Nathan Lynch @ 2014-07-18 17:28 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Heiko Carstens, linux-mm@kvack.org, Paul Mackerras,
H. Peter Anvin, linux-arch, linux-s390@vger.kernel.org,
Richard Weinberger, X86 ML, Ingo Molnar, Catalin Marinas,
Fenghua Yu, user-mode-linux-devel@lists.sourceforge.net,
Will Deacon, Jeff Dike, Chris Metcalf, Thomas Gleixner,
linux-arm-kernel@lists.infradead.org, Tony Luck,
linux-kernel@vger.kernel.org, Martin Schwidefsky,
linux390@de.ibm.com, Andrew Morton, linuxppc-dev
In-Reply-To: <CALCETrXve-=N5yzqDw2YQee4BmC6sb8GYWYJcV2780V38OuJiQ@mail.gmail.com>
On 07/18/2014 11:53 AM, Andy Lutomirski wrote:
>
> On Jul 18, 2014 3:20 AM, "Richard Weinberger" <richard@nod.at
> <mailto:richard@nod.at>> wrote:
>>
>> Am 18.07.2014 12:14, schrieb Will Deacon:
>> > On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote:
>> >> On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski
> <luto@amacapital.net <mailto:luto@amacapital.net>> wrote:
>> >>> The core mm code will provide a default gate area based on
>> >>> FIXADDR_USER_START and FIXADDR_USER_END if
>> >>> !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
>> >>>
>> >>> This default is only useful for ia64. arm64, ppc, s390, sh, tile,
>> >>> 64-bit UML, and x86_32 have their own code just to disable it. arm,
>> >>> 32-bit UML, and x86_64 have gate areas, but they have their own
>> >>> implementations.
>> >>>
>> >>> This gets rid of the default and moves the code into ia64.
>> >>>
>> >>> This should save some code on architectures without a gate area: it's
>> >>> now possible to inline the gate_area functions in the default case.
>> >>
>> >> Can one of you pull this somewhere? Otherwise I can put it somewhere
>> >> stable and ask for -next inclusion, but that seems like overkill for a
>> >> single patch.
>>
>> For the um bits:
>> Acked-by: Richard Weinberger <richard@nod.at <mailto:richard@nod.at>>
>>
>> > I'd be happy to take the arm64 part, but it doesn't feel right for mm/*
>> > changes (or changes to other archs) to go via our tree.
>> >
>> > I'm not sure what the best approach is if you want to send this via
> a single
>> > tree. Maybe you could ask akpm nicely?
>>
>> Going though Andrew's tree sounds sane to me.
>
> Splitting this will be annoying: I'd probably have to add a flag asking
> for the new behavior, update all the arches, then remove the flag. The
> chance of screwing up bisectability in the process seems pretty high.
> This seems like overkill for a patch that mostly deletes code.
>
> Akpm, can you take this?
FWIW:
Acked-by: Nathan Lynch <nathan_lynch@mentor.com>
This patch allows me to avoid adding a bunch of empty hooks to arch/arm
when adding VDSO support:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/268045.html
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Tejun Heo @ 2014-07-18 18:00 UTC (permalink / raw)
To: Nish Aravamudan
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <CAOhV88PyBK3WxDjG1H0hUbRhRYzPOzV8eim5DuOcgObe-FtFYg@mail.gmail.com>
Hello,
On Fri, Jul 18, 2014 at 10:42:29AM -0700, Nish Aravamudan wrote:
> So, to be clear, this is not *necessarily* about memoryless nodes. It's
> about the semantics intended. The workqueue code currently calls
> cpu_to_node() in a few places, and passes that node into the core MM as a
> hint about where the memory should come from. However, when memoryless
> nodes are present, that hint is guaranteed to be wrong, as it's the nearest
> NUMA node to the CPU (which happens to be the one its on), not the nearest
> NUMA node with memory. The hint is correctly specified as cpu_to_mem(),
It's telling the allocator the node the CPU is on. Choosing and
falling back the actual allocation is the allocator's job.
> which does the right thing in the presence or absence of memoryless nodes.
> And I think encapsulates the hint's semantics correctly -- please give me
> memory from where I expect it, which is the closest NUMA node.
I don't think it does. It loses information at too high a layer.
Workqueue here doesn't care how memory subsystem is structured, it's
just telling the allocator where it's at and expecting it to do the
right thing. Please consider the following scenario.
A - B - C - D - E
Let's say C is a memory-less node. If we map from C to either B or D
from individual users and that node can't serve that memory request,
the allocator would fall back to A or E respectively when the right
thing to do would be falling back to D or B respectively, right?
This isn't a huge issue but it shows that this is the wrong layer to
deal with this issue. Let the allocators express where they are.
Choosing and falling back belong to the memory allocator. That's the
only place which has all the information that's necessary and those
details must be contained there. Please don't leak it to memory
allocator users.
Thanks.
--
tejun
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Tejun Heo @ 2014-07-18 18:01 UTC (permalink / raw)
To: Nish Aravamudan
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <20140718180008.GC13012@htj.dyndns.org>
On Fri, Jul 18, 2014 at 02:00:08PM -0400, Tejun Heo wrote:
> This isn't a huge issue but it shows that this is the wrong layer to
> deal with this issue. Let the allocators express where they are.
^
allocator users
> Choosing and falling back belong to the memory allocator. That's the
> only place which has all the information that's necessary and those
> details must be contained there. Please don't leak it to memory
> allocator users.
--
tejun
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Nish Aravamudan @ 2014-07-18 18:12 UTC (permalink / raw)
To: Tejun Heo
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <20140718180008.GC13012@htj.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3191 bytes --]
Hi Tejun,
[I found the other thread where you made these points, thanks you for
expressing them so clearly again!]
On Fri, Jul 18, 2014 at 11:00 AM, Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Fri, Jul 18, 2014 at 10:42:29AM -0700, Nish Aravamudan wrote:
> > So, to be clear, this is not *necessarily* about memoryless nodes. It's
> > about the semantics intended. The workqueue code currently calls
> > cpu_to_node() in a few places, and passes that node into the core MM as
a
> > hint about where the memory should come from. However, when memoryless
> > nodes are present, that hint is guaranteed to be wrong, as it's the
nearest
> > NUMA node to the CPU (which happens to be the one its on), not the
nearest
> > NUMA node with memory. The hint is correctly specified as cpu_to_mem(),
>
> It's telling the allocator the node the CPU is on. Choosing and
> falling back the actual allocation is the allocator's job.
Ok, I agree with you then, if that's all the semantic is supposed to be.
But looking at the comment for kthread_create_on_node:
* If thread is going to be bound on a particular cpu, give its node
* in @node, to get NUMA affinity for kthread stack, or else give -1.
so the API interprets it as a suggestion for the affinity itself, *not* the
node the kthread should be on. Piddly, yes, but actually I have another
thought altogether, and in reviewing Jiang's patches this seems like the
right approach:
why aren't these callers using kthread_create_on_cpu()? That API was
already change to use cpu_to_mem() [so one change, rather than of all over
the kernel source]. We could change it back to cpu_to_node and push down
the knowledge about the fallback.
> > which does the right thing in the presence or absence of memoryless
nodes.
> > And I think encapsulates the hint's semantics correctly -- please give
me
> > memory from where I expect it, which is the closest NUMA node.
>
> I don't think it does. It loses information at too high a layer.
> Workqueue here doesn't care how memory subsystem is structured, it's
> just telling the allocator where it's at and expecting it to do the
> right thing. Please consider the following scenario.
>
> A - B - C - D - E
>
> Let's say C is a memory-less node. If we map from C to either B or D
> from individual users and that node can't serve that memory request,
> the allocator would fall back to A or E respectively when the right
> thing to do would be falling back to D or B respectively, right?
Yes, this is a good point. But honestly, we're not really even to the point
of talking about fallback here, at least in my testing, going off-node at
all causes SLUB-configured slabs to deactivate, which then leads to an
explosion in the unreclaimable slab.
> This isn't a huge issue but it shows that this is the wrong layer to
> deal with this issue. Let the allocators express where they are.
> Choosing and falling back belong to the memory allocator. That's the
> only place which has all the information that's necessary and those
> details must be contained there. Please don't leak it to memory
> allocator users.
Ok, I will continue to work at that level of abstraction.
Thanks,
Nish
[-- Attachment #2: Type: text/html, Size: 3817 bytes --]
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Tejun Heo @ 2014-07-18 18:19 UTC (permalink / raw)
To: Nish Aravamudan
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <CAOhV88O03zCsv_3eadEKNv1D1RoBmjWRFNhPjEHawF9s71U0JA@mail.gmail.com>
Hello,
On Fri, Jul 18, 2014 at 11:12:01AM -0700, Nish Aravamudan wrote:
> why aren't these callers using kthread_create_on_cpu()? That API was
It is using that. There just are other data structures too.
> already change to use cpu_to_mem() [so one change, rather than of all over
> the kernel source]. We could change it back to cpu_to_node and push down
> the knowledge about the fallback.
And once it's properly solved, please convert back kthread to use
cpu_to_node() too. We really shouldn't be sprinkling the new subtly
different variant across the kernel. It's wrong and confusing.
> Yes, this is a good point. But honestly, we're not really even to the point
> of talking about fallback here, at least in my testing, going off-node at
> all causes SLUB-configured slabs to deactivate, which then leads to an
> explosion in the unreclaimable slab.
I don't think moving the logic inside allocator proper is a huge
amount of work and this isn't the first spillage of this subtlety out
of allocator proper. Fortunately, it hasn't spread too much yet.
Let's please stop it here. I'm not saying you shouldn't or can't fix
the off-node allocation.
Thanks.
--
tejun
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Nish Aravamudan @ 2014-07-18 18:47 UTC (permalink / raw)
To: Tejun Heo
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <20140718181947.GE13012@htj.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
On Fri, Jul 18, 2014 at 11:19 AM, Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Fri, Jul 18, 2014 at 11:12:01AM -0700, Nish Aravamudan wrote:
> > why aren't these callers using kthread_create_on_cpu()? That API was
>
> It is using that. There just are other data structures too.
Sorry, I might not have been clear.
Why are any callers of the format kthread_create_on_node(...,
cpu_to_node(cpu), ...) not using kthread_create_on_cpu(..., cpu, ...)?
In total in Linus' tree, there are only two APIs that use
kthread_create_on_cpu() -- smpboot_create_threads() and
smpboot_register_percpu_thread(). Neither of those seem to be used by the
workqueue code that I can see as of yet.
> > already change to use cpu_to_mem() [so one change, rather than of all
over
> > the kernel source]. We could change it back to cpu_to_node and push down
> > the knowledge about the fallback.
>
> And once it's properly solved, please convert back kthread to use
> cpu_to_node() too. We really shouldn't be sprinkling the new subtly
> different variant across the kernel. It's wrong and confusing.
I understand what you mean, but it's equally wrong for the kernel to be
wasting GBs of slab. Different kinds of wrongness :)
> > Yes, this is a good point. But honestly, we're not really even to the
point
> > of talking about fallback here, at least in my testing, going off-node
at
> > all causes SLUB-configured slabs to deactivate, which then leads to an
> > explosion in the unreclaimable slab.
>
> I don't think moving the logic inside allocator proper is a huge
> amount of work and this isn't the first spillage of this subtlety out
> of allocator proper. Fortunately, it hasn't spread too much yet.
> Let's please stop it here. I'm not saying you shouldn't or can't fix
> the off-node allocation.
It seems like an additional reasonable approach would be to provide a
suitable _cpu() API for the allocators. I'm not sure why saying that
callers should know about NUMA (in order to call cpu_to_node() in every
caller) is any better than saying that callers should know about memoryless
nodes (in order to call cpu_to_mem() in every caller instead) -- when at
least in several cases that I've seen the relevant data is what CPU we're
expecting to run or are running on. Seems like the _cpu API would specify
-- please allocate memory local to this CPU, wherever it is?
Thanks,
Nish
[-- Attachment #2: Type: text/html, Size: 2862 bytes --]
^ permalink raw reply
* Re: [RFC 0/2] Memoryless nodes and kworker
From: Tejun Heo @ 2014-07-18 18:58 UTC (permalink / raw)
To: Nish Aravamudan
Cc: Fenghua Yu, Tony Luck, linux-ia64, Nishanth Aravamudan,
linux-kernel@vger.kernel.org, Linux Memory Management List,
David Rientjes, Joonsoo Kim, linuxppc-dev, Jiang Liu, Wanpeng Li
In-Reply-To: <CAOhV88Mby_vrLPtRsRNO724-_ABEL06Fc1mMwjgq7LWw-uxeAw@mail.gmail.com>
Hello,
On Fri, Jul 18, 2014 at 11:47:08AM -0700, Nish Aravamudan wrote:
> Why are any callers of the format kthread_create_on_node(...,
> cpu_to_node(cpu), ...) not using kthread_create_on_cpu(..., cpu, ...)?
Ah, okay, that's because unbound workers are NUMA node affine, not
CPU.
> It seems like an additional reasonable approach would be to provide a
> suitable _cpu() API for the allocators. I'm not sure why saying that
> callers should know about NUMA (in order to call cpu_to_node() in every
> caller) is any better than saying that callers should know about memoryless
> nodes (in order to call cpu_to_mem() in every caller instead) -- when at
It is better because that's what they want to express - "I'm on this
memory node, please allocate memory on or close to this one". That's
what the caller cares about. Calling with cpu could be an option but
you'll eventually run into cases where you end up having to map back
NUMA node id to a CPU on it, which will probably feel at least a bit
silly. There are things which really are per-NUMA node.
So, let's please express what needs to be expressed. Massaging around
it can be useful at times but that doesn't seem to be the case here.
Thanks.
--
tejun
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox