linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vineet Gupta <vineet.gupta1@synopsys.com>
To: Eugeniy Paltsev <eugeniy.paltsev@synopsys.com>,
	"linux-snps-arc@lists.infradead.org" 
	<linux-snps-arc@lists.infradead.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Alexey Brodkin" <alexey.brodkin@synopsys.com>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] ARC: fix memory nodes topology in case of highmem enabled
Date: Wed, 3 Apr 2019 19:29:22 +0000	[thread overview]
Message-ID: <C2D7FE5348E1B147BCA15975FBA230750146440183@US01WEMBX2.internal.synopsys.com> (raw)
In-Reply-To: 20190401184242.7636-1-Eugeniy.Paltsev@synopsys.com

On 4/1/19 11:43 AM, Eugeniy Paltsev wrote:
> Tweak generic node topology in case of CONFIG_HIGHMEM enabled to
> prioritize allocations from ZONE_HIGHMEM to avoid ZONE_NORMAL
> pressure.

Can you explain the "pressure" part a bit more concretely - as in when did you saw
crashes, oom, yadi yada ....

> Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
> ---
> Tested on both NSIM and HSDK (require memory apertures remmaping and
> device tree patching)

How can one test this patch w/o those - are they secret which rest of world should
not know about :-)
Jokes apart, at the very least, please include them as part of changelog "as
indicative code" which people can use in testing if needed.
Preferably they need to be part of platform code under the right config (HIGHMEM +
PAE etc)

FWIW as mentioned on other thread, for my setup of PAE + 2GB  HIGHMEM (so 2 nodes)
1. I didn't need any AXI aperture remapping
2. Didn't see any extra mem pressure / failures when running glibc testsuite

>
>  arch/arc/include/asm/Kbuild     |  1 -
>  arch/arc/include/asm/topology.h | 30 ++++++++++++++++++++++++++++++
>  2 files changed, 30 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arc/include/asm/topology.h
>
> diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
> index caa270261521..e64e0439baff 100644
> --- a/arch/arc/include/asm/Kbuild
> +++ b/arch/arc/include/asm/Kbuild
> @@ -18,7 +18,6 @@ generic-y += msi.h
>  generic-y += parport.h
>  generic-y += percpu.h
>  generic-y += preempt.h
> -generic-y += topology.h
>  generic-y += trace_clock.h
>  generic-y += user.h
>  generic-y += vga.h
> diff --git a/arch/arc/include/asm/topology.h b/arch/arc/include/asm/topology.h
> new file mode 100644
> index 000000000000..c273506931c9
> --- /dev/null
> +++ b/arch/arc/include/asm/topology.h
> @@ -0,0 +1,30 @@
> +#ifndef _ASM_ARC_TOPOLOGY_H
> +#define _ASM_ARC_TOPOLOGY_H
> +
> +/*
> + * On ARC (w/o PAE) HIGHMEM addresses are smaller (0x0 based) than addresses in
> + * NORMAL aka low memory (0x8000_0000 based).
> + * Thus HIGHMEM on ARC is imlemented with DISCONTIGMEM which requires multiple

s/imlemented/implemented
> + * nodes. So here is memory node map depending on the CONFIG_HIGHMEM
> + * enabled/disabled:
> + *
> + * CONFIG_HIGHMEM disabled:
> + *  - node 0: ZONE_NORMAL memory only.
> + *
> + * CONFIG_HIGHMEM enabled:
> + *  - node 0: ZONE_NORMAL memory only.
> + *  - node 1: ZONE_HIGHMEM memory only.

Perhaps we could reduce the text above by having 2 lines and adding a "()" comment
for node 1

+ *  - node 0: ZONE_NORMAL memory  (always)
+ *  - node 1: ZONE_HIGHMEM memory (HIGHMEM only)



> + *
> + * In case of CONFIG_HIGHMEM enabled we tweak generic node topology and mark
> + * node 1 as the closest to all CPUs to prioritize allocations from ZONE_HIGHMEM
> + * where it is possible to avoid ZONE_NORMAL pressure.
> + */
> +#ifdef CONFIG_HIGHMEM
> +#define cpu_to_node(cpu)	((void)(cpu), 1)
> +#define cpu_to_mem(cpu)		((void)(cpu), 1)
> +#define cpumask_of_node(node)	((node) == 1 ? cpu_online_mask : cpu_none_mask)
> +#endif /* CONFIG_HIGHMEM */
> +
> +#include <asm-generic/topology.h>
> +
> +#endif /* _ASM_ARC_TOPOLOGY_H */

Otherwise LGTM. I would like to give this a spin myself, but first need to know
what tests cause the increased failures which this patch mitigates.

Thx,
-Vineet

      reply	other threads:[~2019-04-03 19:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-01 18:42 [PATCH] ARC: fix memory nodes topology in case of highmem enabled Eugeniy Paltsev
2019-04-03 19:29 ` Vineet Gupta [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C2D7FE5348E1B147BCA15975FBA230750146440183@US01WEMBX2.internal.synopsys.com \
    --to=vineet.gupta1@synopsys.com \
    --cc=alexey.brodkin@synopsys.com \
    --cc=eugeniy.paltsev@synopsys.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-snps-arc@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).