Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On 07/18/2014 11:53 AM, Andy Lutomirski wrote: > > On Jul 18, 2014 3:20 AM, "Richard Weinberger" > 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 Lutomi

Re: [RFC 0/2] Memoryless nodes and kworker

On Fri, Jul 18, 2014 at 11:19 AM, Tejun Heo 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

Re: [RFC 0/2] Memoryless nodes and kworker

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 wrote: > > Hello, > > On Fri, Jul 18, 2014 at 10:42:29AM -0700, Nish Aravamudan wrote: > > So, to be clear, this is not *necessarily* abo

Re: [RFC 0/2] Memoryless nodes and kworker

Hi Tejun, On Fri, Jul 18, 2014 at 4:20 AM, Tejun Heo 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 (ex

Re: [RFC 1/2] workqueue: use the nearest NUMA node, not the local one

[ 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 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

Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On Jul 18, 2014 3:20 AM, "Richard Weinberger" 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 wrote: > >>> The core mm code will provide a default gate area based on > >

Re: [PATCH] powerpc: Add cputable definition for POWER8 DD1

On Fri, 2014-07-18 at 15:10 +1000, Michael Neuling wrote: > On Fri, 2014-07-18 at 11:41 +0930, Joel Stanley wrote: > > These processors do not currently support doorbell IPIs, so remove them > > from the feature list if we are at DD 1.xx for the 0x004d part. > > We GAed with DD2.1 and generally we

[PATCH] Add support for hardware threads on e6500.

From: Andy Fleming The general idea is that each core will release all of its threads into the secondary thread startup code, which will eventually wait in the secondary core holding area, for the appropriate bit in the PACA to be set. The kick_cpu function pointer will set that bit in the PACA,

Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On 07/18/2014 09:53 AM, Andy Lutomirski wrote: > > 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 f

Re: [RFC 0/2] Memoryless nodes and kworker

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

Re: [RFC 0/2] Memoryless nodes and kworker

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 so

Re: [RFC 0/2] Memoryless nodes and kworker

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 fa

Re: [RFC 0/2] Memoryless nodes and kworker

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 ab

Re: [PATCH 1/5] memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE

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 man

Re: [PATCH] powerpc : dma-mapping : Check null condition for dev->archdata.dma_ops

On 7/18/14, Nikhil Badola 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 NU

Re: [RFC 0/2] Memoryless nodes and kworker

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) >

Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

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 wrote: >>> The core mm code will provide a default gate area based on >>> FIXADDR_USER_START and FIXADDR_USER_END if >>> !defined(__HAVE_

Re: [PATCH 1/2] ASoC: fsl_sai: Reset FIFOs after disabling TE/RE

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 C

[PATCH] powerpc : dma-mapping : Check null condition for dev->archdata.dma_ops

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 --- arch/powerpc/include/asm/dma-mapping.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff

Re: [PATCH v3] arm64, ia64, ppc, s390, sh, tile, um, x86, mm: Remove default gate area

On Tue, Jul 15, 2014 at 03:47:26PM +0100, Andy Lutomirski wrote: > On Sun, Jul 13, 2014 at 1:01 PM, Andy Lutomirski 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).

Re: [PATCH 0/5] memory-hotplug: suitable memory should go to ZONE_MOVABLE

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: >>

Re: [PATCH 2/5] memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE

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 > --- > arch/x86/mm/init_32.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/x86/mm/init_32.c

Re: [PATCH 0/5] memory-hotplug: suitable memory should go to ZONE_MOVABLE

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 0x4000 > /sys/devices/system/memor

RE: [PATCH v5 4/5] KVM: PPC: Alow kvmppc_get_last_inst() to fail

> -Original Message- > From: Alexander Graf [mailto:ag...@suse.de] > Sent: Thursday, July 17, 2014 5:21 PM > To: Caraman Mihai Claudiu-B02008; kvm-...@vger.kernel.org > Cc: k...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH v5 4/5] KVM: PPC: Alow kvmppc_get_last_inst(

[PATCH 4/5] memory-hotplug: sh: suitable memory should go to ZONE_MOVABLE

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 --- 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..ff9dec

Re: [RFC 1/2] workqueue: use the nearest NUMA node, not the local one

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 prefe

[PATCH 5/5] memory-hotplug: powerpc: suitable memory should go to ZONE_MOVABLE

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 --- 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 10064

[PATCH 3/5] memory-hotplug: ia64: suitable memory should go to ZONE_MOVABLE

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 --- 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/

[PATCH 0/5] memory-hotplug: suitable memory should go to ZONE_MOVABLE

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 0x4000 > /sys/devices/system/memory/probe [ 28.613895] init_memory_mapping: [mem 0x400

[PATCH 1/5] memory-hotplug: x86_64: suitable memory should go to ZONE_MOVABLE

This patch add new memory to ZONE_MOVABLE if movable zone is setup and lower than newly added memory for x86_64. Signed-off-by: Wang Nan --- arch/x86/mm/init_64.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index df

[PATCH 2/5] memory-hotplug: x86_32: suitable memory should go to ZONE_MOVABLE

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 --- 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

Re: [PATCH V3 0/3] Add new PowerPC specific ELF core notes

On 07/18/2014 04:53 AM, Sam Bobroff wrote: > On 17/07/14 21:14, Michael Neuling wrote: >> >> On Jul 17, 2014 9:11 PM, "Benjamin Herrenschmidt" >> mailto:b...@kernel.crashing.org>> wrote: >>> > >> Outstanding Issues >> == >> (1) Running DSCR register value inside a tr

Re: [PATCH v4 2/2] Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8

On Fri, Jul 18, 2014 at 02:18:43PM +1000, Stewart Smith wrote: > The POWER8 processor has a Micro Partition Prefetch Engine, which is > a fancy way of saying "has way to store and load contents of L2 or > L2+MRU way of L3 cache". We initiate the storing of the log (list of > addresses) using the lo

Re: [PATCH v4 1/2] Split out struct kvmppc_vcore creation to separate function

On Fri, Jul 18, 2014 at 02:18:42PM +1000, Stewart Smith wrote: > No code changes, just split it out to a function so that with the addition > of micro partition prefetch buffer allocation (in subsequent patch) looks > neater and doesn't require excessive indentation. > > Signed-off-by: Stewart Smi

Re: [PATCH] CMA: generalize CMA reserved area management functionality (fixup)

Hello, On 2014-07-18 00:06, Andrew Morton wrote: On Thu, 17 Jul 2014 11:36:07 +0200 Marek Szyprowski wrote: MAX_CMA_AREAS is used by other subsystems (i.e. arch/arm/mm/dma-mapping.c), so we need to provide correct definition even if CMA is disabled. This patch fixes this issue. Reported-by: