linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Punit Agrawal <punit.agrawal@arm.com>
To: Xie XiuQi <xiexiuqi@huawei.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	 Michal Hocko <mhocko@kernel.org>,
	 Hanjun Guo <guohanjun@huawei.com>,
	 Bjorn Helgaas <helgaas@kernel.org>,
	 <tnowicki@caviumnetworks.com>,  <linux-pci@vger.kernel.org>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	 "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	 Will Deacon <will.deacon@arm.com>,
	 Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	 Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	 <linux-mm@kvack.org>,  <wanghuiqiang@huawei.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 Bjorn Helgaas <bhelgaas@google.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	 zhongjiang <zhongjiang@huawei.com>,
	 linux-arm <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/2] arm64: avoid alloc memory on offline node
Date: Wed, 20 Jun 2018 12:51:22 +0100	[thread overview]
Message-ID: <87602d3ccl.fsf@e105922-lin.cambridge.arm.com> (raw)
In-Reply-To: <814205eb-ae86-a519-bed0-f09b8e2d3a02@huawei.com> (Xie XiuQi's message of "Wed, 20 Jun 2018 11:31:34 +0800")

Xie XiuQi <xiexiuqi@huawei.com> writes:

> Hi Lorenzo, Punit,
>
>
> On 2018/6/20 0:32, Lorenzo Pieralisi wrote:
>> On Tue, Jun 19, 2018 at 04:35:40PM +0100, Punit Agrawal wrote:
>>> Michal Hocko <mhocko@kernel.org> writes:
>>>
>>>> On Tue 19-06-18 15:54:26, Punit Agrawal wrote:
>>>> [...]
>>>>> In terms of $SUBJECT, I wonder if it's worth taking the original patch
>>>>> as a temporary fix (it'll also be easier to backport) while we work on
>>>>> fixing these other issues and enabling memoryless nodes.
>>>>
>>>> Well, x86 already does that but copying this antipatern is not really
>>>> nice. So it is good as a quick fix but it would be definitely much
>>>> better to have a robust fix. Who knows how many other places might hit
>>>> this. You certainly do not want to add a hack like this all over...
>>>
>>> Completely agree! I was only suggesting it as a temporary measure,
>>> especially as it looked like a proper fix might be invasive.
>>>
>>> Another fix might be to change the node specific allocation to node
>>> agnostic allocations. It isn't clear why the allocation is being
>>> requested from a specific node. I think Lorenzo suggested this in one of
>>> the threads.
>> 
>> I think that code was just copypasted but it is better to fix the
>> underlying issue.
>> 
>>> I've started putting together a set fixing the issues identified in this
>>> thread. It should give a better idea on the best course of action.
>> 
>> On ACPI ARM64, this diff should do if I read the code correctly, it
>> should be (famous last words) just a matter of mapping PXMs to nodes for
>> every SRAT GICC entry, feel free to pick it up if it works.
>> 
>> Yes, we can take the original patch just because it is safer for an -rc
>> cycle even though if the patch below would do delaying the fix for a
>> couple of -rc (to get it tested across ACPI ARM64 NUMA platforms) is
>> not a disaster.
>
> I tested this patch on my arm board, it works.

I am assuming you tried the patch without enabling support for
memory-less nodes.

The patch de-couples the onlining of numa nodes (as parsed from SRAT)
from NR_CPUS restriction. When it comes to building zonelists, the node
referenced by the PCI controller also has zonelists initialised.

So it looks like a fallback node is setup even if we don't have
memory-less nodes enabled. I need to stare some more at the code to see
why we need memory-less nodes at all then ...

  reply	other threads:[~2018-06-20 11:51 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1527768879-88161-1-git-send-email-xiexiuqi@huawei.com>
     [not found] ` <1527768879-88161-2-git-send-email-xiexiuqi@huawei.com>
     [not found]   ` <20180606154516.GL6631@arm.com>
2018-06-06 20:39     ` [PATCH 1/2] arm64: avoid alloc memory on offline node Bjorn Helgaas
2018-06-07 10:55       ` Michal Hocko
2018-06-07 11:55         ` Hanjun Guo
2018-06-07 12:21           ` Michal Hocko
2018-06-11  3:23             ` Xie XiuQi
2018-06-11  8:52               ` Michal Hocko
2018-06-11 12:32                 ` Xie XiuQi
2018-06-11 13:43                   ` Bjorn Helgaas
2018-06-11 14:53                     ` Michal Hocko
2018-06-12 15:08                       ` Punit Agrawal
2018-06-12 15:20                         ` Michal Hocko
2018-06-13 17:39                         ` Punit Agrawal
2018-06-14  6:23                           ` Hanjun Guo
2018-06-19 12:03                           ` Xie XiuQi
2018-06-19 12:07                             ` Michal Hocko
2018-06-19 12:40                               ` Xie XiuQi
2018-06-19 12:52                               ` Punit Agrawal
2018-06-19 14:08                                 ` Lorenzo Pieralisi
2018-06-19 14:54                                   ` Punit Agrawal
2018-06-19 15:14                                     ` Michal Hocko
2018-06-19 15:35                                       ` Punit Agrawal
2018-06-19 16:32                                         ` Lorenzo Pieralisi
2018-06-20  3:31                                           ` Xie XiuQi
2018-06-20 11:51                                             ` Punit Agrawal [this message]
2018-06-22  8:58                                               ` Hanjun Guo
2018-06-22  9:11                                                 ` Michal Hocko
2018-06-22 10:24                                                   ` Punit Agrawal
2018-06-22 17:42                                                     ` Jonathan Cameron
2018-06-26 17:27                                                       ` Punit Agrawal
2018-06-26 17:27                                                       ` Punit Agrawal

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=87602d3ccl.fsf@e105922-lin.cambridge.arm.com \
    --to=punit.agrawal@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=guohanjun@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mhocko@kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tnowicki@caviumnetworks.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=will.deacon@arm.com \
    --cc=xiexiuqi@huawei.com \
    --cc=zhongjiang@huawei.com \
    /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).