linux-kernel - Re: [PATCH v5 00/14] ACPI NUMA support for ARM64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Apr 2016 09:49:36 +0800
From:	Hanjun Guo <hanjun.guo@...aro.org>
To:	Will Deacon <will.deacon@....com>
Cc:	David Daney <ddaney@...iumnetworks.com>,
	David Daney <ddaney.cavm@...il.com>,
	linux-arm-kernel@...ts.infradead.org,
	Mark Rutland <mark.rutland@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Tony Luck <tony.luck@...el.com>,
	Fenghua Yu <fenghua.yu@...el.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>, Rob Herring <robh+dt@...nel.org>,
	Frank Rowand <frowand.list@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Robert Moore <robert.moore@...el.com>,
	Lv Zheng <lv.zheng@...el.com>,
	Marc Zyngier <Marc.Zyngier@....com>,
	linux-ia64@...r.kernel.org, linux-acpi@...r.kernel.org,
	devel@...ica.org, linux-kernel@...r.kernel.org,
	Robert Richter <rrichter@...ium.com>,
	David Daney <david.daney@...ium.com>
Subject: Re: [PATCH v5 00/14] ACPI NUMA support for ARM64

Hi Will,

On 2016/4/26 21:35, Will Deacon wrote:
> On Tue, Apr 26, 2016 at 09:03:25PM +0800, Hanjun Guo wrote:
>> On 2016/4/26 20:15, Will Deacon wrote:
>>> On Tue, Apr 26, 2016 at 01:31:07PM +0800, Hanjun Guo wrote:
>>>> On 2016/4/26 0:47, David Daney wrote:
>>>>> On 04/25/2016 04:13 AM, Will Deacon wrote:
>>>>>> On Tue, Apr 19, 2016 at 06:40:25PM -0700, David Daney wrote:
>>>>>>> From: David Daney <david.daney@...ium.com>
>>>>>>>
>>>>>>> Based on v16 of device-tree NUMA patch set for arm64 [1],this patch
>>>>>>> set introduce the ACPI based configuration to provide NUMA
>>>>>>> information.
>>>>>>>
>>>>>>> ACPI 5.1 already introduced NUMA support for ARM64, which can get the
>>>>>>> NUMA domain information from SRAT and SLIT table, so parse those two
>>>>>>> tables to get mappings from cpu/mem to numa node configuration and
>>>>>>> system locality.
>>>>>>
>>>>>> Whilst I've queued the main NUMA series for arm64, I'd really like to
>>>>>> see more movement on the generic header file cleanups that you posted
>>>>>> separately:
>>>>>>
>>>>>> http://lkml.kernel.org/r/1456358528-24213-1-git-send-email-ddaney.cavm@gmail.com
>>>>>>
>>>>>
>>>>> FWIW:  Those patches should still apply.  I am carrying them in my
>>>>> development trees, and have not changed them in any way.
>>>
>>> What's your plan for getting them merged?
>>
>> This patch set touches lots of ACPI related file in arch/x86,
>> arch/ia64, and drivers/acpi/ (also arch/arm64), I think it can be
>> merged via ACPI tree by Rafael with your ack to ARM64 code, does
>> it make sense?
>
> It doesn't touch anything in drivers/acpi/... are you following the link
> above?

Sorry, my bad, I though you were talking about this ACPI NUMA support
for ARM64 patch set.

>
>>>>>> Given that this ACPI series already requires some significant cross-arch
>>>>>> interaction (which is actually good!), perhaps extending the clean-up
>>>>>> patches to encompass some of the ACPI bits might make sense, and we can
>>>>>> get that queued as a pre-requisite.
>>>>>
>>>>> The cleanup patches you mention above are really independent of the ACPI
>>>>> things.  I have applied them both before and after the ACPI patches, and
>>>>> both seem to work.  With a quick perusal of the ACPI patches nothing
>>>>> jumps out at me as being a candidate for inclusion in the header file
>>>>> cleanup series.
>>>>
>>>> I agree. My patch set is ACPI related enablement, cleanups and
>>>> consolidations, it would be good to merge as a single patch set
>>>> as it's self-contained.
>>>
>>> Up to you. I just thought you might want to avoid having two sets of
>>> cross-arch changes and the associated merging headaches that go with
>>> that.
>>
>> Good point, as I suggested above, it can go with ACPI tree if it's ok
>> to you and Rafael. The problem we have now is that dt based core NUMA
>> support for ARM64 is queued in your tree, that would be the headache.
>
> Sorry, but if you wanted me *not* to queue the patches, then you should
> have said so (similarly, if you wanted a stable branch). I'm not rebasing
> our for-next/core branch now.

I misread the message above, I'm really sorry if I did something
offending you, I didn't mean that.

How about this patch set? We only get few comments on it, your
comments on it are appreciated.

Thanks
Hanjun