From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752000AbcELUki (ORCPT ); Thu, 12 May 2016 16:40:38 -0400 Received: from mail-bn1bon0099.outbound.protection.outlook.com ([157.56.111.99]:21504 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751893AbcELUkd (ORCPT ); Thu, 12 May 2016 16:40:33 -0400 Authentication-Results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=caviumnetworks.com; Message-ID: <5734EA38.2040206@caviumnetworks.com> Date: Thu, 12 May 2016 13:40:24 -0700 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Catalin Marinas CC: "Rafael J. Wysocki" , Will Deacon , Mark Rutland , , David Daney , Robert Moore , Lv Zheng , "H. Peter Anvin" , Frank Rowand , , , Ingo Molnar , Grant Likely , Len Brown , Fenghua Yu , Marc Zyngier , Jon Masters , Robert Richter , Rob Herring , Thomas Gleixner , , , Tony Luck , , Hanjun Guo , Ganapatrao Kulkarni Subject: Re: [PATCH v6 13/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT References: <1461780436-27182-1-git-send-email-ddaney.cavm@gmail.com> <1461780436-27182-14-git-send-email-ddaney.cavm@gmail.com> <20160511103929.GC3051@e104818-lin.cambridge.arm.com> <5733C8F5.6090206@caviumnetworks.com> <20160512094915.GD11226@e104818-lin.cambridge.arm.com> <5734A0CC.8010600@caviumnetworks.com> <20160512162449.GK11226@e104818-lin.cambridge.arm.com> In-Reply-To: <20160512162449.GK11226@e104818-lin.cambridge.arm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [64.2.3.194] X-ClientProxiedBy: SN1PR0701CA0021.namprd07.prod.outlook.com (10.162.96.31) To SN1PR07MB2144.namprd07.prod.outlook.com (10.164.47.14) X-MS-Office365-Filtering-Correlation-Id: fd7c0537-f696-4f85-508c-08d37aa5a7e0 X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2144;2:kTSWDlyfbrOAD4OLi6izuXjaa97m6clGhQnQuUAKfx+6yQ2B9iZ9/ed27uBlPDj1obmn/ZHIDk0wEYzTqmFAAk9OVb/7bY0vdMh3xkWOMFSK3Bss/VSURMpspzuZ8Dl0UdQpA5vEV3tQMcZM6kuHDdXvAgLJ0BOgVcncJYxqkX7wubJNPCqVFPPM3tBIDf27;3:MhLauvuTXKNYK6P5bYv36/F0JymVdRvtEzCMekmImuFdhwxUv+Y7OxDDuJZdfAbe5nH0Uuh4Zdc7YNXWsUoQPrblRCrHmZjmr3Ftwgny0ZEPBs5Xb3tjQgoGNaKvObCy;25:oStbW7bvZr+A7GxFCwNB9HmVCGnGqWBsIkx831TqYFVcKAfxqOBBkDuYosJQKEeBCYuQixlCNozfDHt1j0DFp1j40PmIeJ9C7TsoRVezaRLq/c2ZIXv+dkOvkIXjpbrq/SrobukKIZe6fE8g/OeHS68/xcpow4IMZhb8K6GYDiMWIvBaV86JEH9HGoXRM2u2nK0NEPgZrGRDAwVuxiHAOn98Ju0XHIMMjRQ0nk9/HEbLHxPts/uVDJrjXNkfLtjqjYwik70B2jeGC67mBQ3UYseMYTYRmw0WOTYdSg3K2vQElABOy/t7P/M1Jk6XEzf1AZF2crZoYpn+6Jk7GbSlJWJL9yPJPfULB/f5+i1Chv8GBlhI1jyNpd1u8bPQIbk8JZU6CVRveizonq9RyyFzM5AkaZx7/O0cmTyT8KkKHAs= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2144; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2144;20:/3juw6WorI3rpH5xs2vPBEWdIPTUG5PyJBDg1n+qnk8gVkeY8Ptc2uZOciCQLBapth7xu9t/Rq61v01/TkEOv0IQWR4bZ+ZtF9m7s9qQ9wKwEgIsyR/oY0Rm/ytjuPAKa9Jr6HsWaU7FYCOfL7TClrv6efOfa1ws5BIrQ7BH2rED+OxmFYwhwuGj8V2LV9E7JnVyPCV0XLq7t89/fqSIYESZOVSPlXk88xpJuLwRDFOqHnGnwSeOe0BxlN2n4e4QgnyI0OuN5jMqjjEmd6N3p7ReQ6O2NQDEGTnXmBI3dMAVFf4UhD8Rrt6euIPEmiOVk3qL/Qy4tQiKopZkhnVayIl8Y9hnYWnD+2HY6VelcpPU62W7Pj0V3DAHLVoaftrTzYXLKlorRzXQhLk4gQ3INW+sxw05n8BqoJBOzXUE7LIjGMoUN+LrWs4yDcYM4N4CYOW2Zoee3fJZ7/x3RXJvRCyvQ8dNsUb+dtyAQ65TIqKiZLJtfFyttveHC+O0EVA7Sl4FfU8OlpcKlMp2Noa2M5oV7Ju5Gx/2nx/IXJ8fKjGmn8SGSm5570POeHw2xds9KMPKMp7WZ6A6axmK97yTy2V85hjCXh0D+ZkyUHv80hc= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001);SRVR:SN1PR07MB2144;BCL:0;PCL:0;RULEID:;SRVR:SN1PR07MB2144; X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2144;4:1nVCVvYb3+v34gTmOdCfHdUqNLkfLn+zVA7grbAx2wmPXWDfZhHBjem7U0cHjg6daUgQ+Zl4G5h9wNBxg8Z7oYkayYMiH7nyy52UQlyi2MvQ1t23cz5/WL4VZ5mcNbH1IDNxhneld6OujyBjRO8g7eCl5rjwIW+0kQUQsBDJQdUIJ43YJ2ebVa21BPjkrFXGGI6QR+TaFk0DT6Q/g9squSVfMRaJYKuDEoIurKQwAwsNhB9XluyF1rYmRHLWRdAerI3aA+2DRuVTGU0tQraU/+uJo7afL6BmpWus99s6nD1twH7YrLVtkDClFGEUBJpKDUmmRMmArjB5Wt8mgWZt5ZHsRRzW47neoYRetiDu93qlXaKYSB+93HnzWd+o1NbF X-Forefront-PRVS: 0940A19703 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(24454002)(377454003)(586003)(33656002)(5004730100002)(4001430100002)(23756003)(66066001)(87266999)(5008740100001)(50986999)(54356999)(230700001)(65956001)(65806001)(76176999)(65816999)(6116002)(3846002)(47776003)(92566002)(64126003)(36756003)(50466002)(81166006)(42186005)(4326007)(2906002)(77096005)(2950100001)(110136002)(107886002)(53416004)(93886004)(189998001)(83506001)(4001350100001)(59896002)(575784001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR07MB2144;H:dl.caveonetworks.com;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;SN1PR07MB2144;23:njlT7qwUyjXZow4QHWXvgI55p1tbmaefWBgWXpO?= =?iso-8859-1?Q?LPdeO2jTg6lrRTRcqt85VYI2VSXYjAFraj7mkWnvMFd3Touz5pG1p+mfoK?= =?iso-8859-1?Q?4evpRF8PM6mU1beyuKTVHJBUqOoKLKTM/J9qib/qrn4avOjNbNvLE6kKMz?= =?iso-8859-1?Q?ovumVr5aNIwOx74y6+DIz9a1BuNygkMxHcTo8MdvdHg0QVRPj6EzdCAdxc?= =?iso-8859-1?Q?1tcm0QGOZ/o7QHW33nm20k9eCyeGVfiF6gUMnHDsRi2Kh7RVVCCnTbMSYw?= =?iso-8859-1?Q?QGpKcVYh7LmwAp9tOCI8Csb02LSaL/b/VlHbUvpBqAi32CGOnFoilrZKKw?= =?iso-8859-1?Q?rM7fg4be7g/E5Ju8HV1bMTNk1xT3xTcXt+sw6CO9imYNtwKmma35vMZK0U?= =?iso-8859-1?Q?FVOI7KKB3T4Q/zJGR07baJmqijR+RjH1oGLXHKXD4ofhGyKi05GVre8bhQ?= =?iso-8859-1?Q?hTsZqBHKUvOVj/Cf5UB2G1EAJ48qukqjH7QF7L0Gi4CI3nKH4RVg8aKMoK?= =?iso-8859-1?Q?nCKvd3aXSlk3p4yrzdFM8LO/Jp6k+JxQeZ556lIlr/8UEpxQ/eCwO23D3b?= =?iso-8859-1?Q?WkGNuv3u/OjwvZKw7bGbqet7Hl7tje9gZ0WSaVculNap2hUNhsFjmVnhTu?= =?iso-8859-1?Q?hgxKZBGRaFwcBnHO0g9ks3QucArqfsycA8Ve2u1qr6WSyMCW5OuV66klwA?= =?iso-8859-1?Q?g2ThoBDmRqh2YzDyKGPRHvlGDX89cFM/eFORrbq/7qbaIaaUdjW4RPeYbM?= =?iso-8859-1?Q?uD2sRuHTTgiN/4IdTm/CNQiBI+YgkA1t7JA9cIdu7S3RKUaUO6DhqILXrI?= =?iso-8859-1?Q?MalDG01JVud9teGFnUPRBFrrEIDYXeBCFsyg8+vKSsaewzEjhMg2cHR67d?= =?iso-8859-1?Q?Zh4vowB5VoS6cwz9s9Vw0+VkXFmtYpvE6ndGt5h8IU/qXqHBGmVBm+PB8N?= =?iso-8859-1?Q?jUUX4Dh3Gwy/knANKIJvioko1D22OCVWcJxP09fi8fI4EqtZjJJ5On07GG?= =?iso-8859-1?Q?CcI3dvX/GzBN+gtnkKPnVjIvPnz3oaa4cLdXOml6A6TJYYoF0aCkdYJZVs?= =?iso-8859-1?Q?R3PKLTYSXE0Q68gxxDl36if9D8gKg7ALL7taVtJzzpJl8x1CKxG9RyTHZn?= =?iso-8859-1?Q?2mmCGPgBuPXAIUUkpZN+EdbwIJw=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR07MB2144;5:rh2mZCsPR60hqe33KUc0G6YNbzgMshPEPGXvuEhqf3GQH5PMG47yHPzojveuMKq4c4HgqXWBUvSXopaUTFiK6mAyamgWXcD0oJcC2bhb1RaPyjuP5nchyhDykUkxO0E2YbffTbYYidJFuLUs8nfh2g==;24:qnyhCnSM12kE0fCB+F7vTk/xNTt/+C0VbFE+DaPlUJUXPURahive6IJn9kJMrKIw0TYi9BIT4QjqEf4FQJOKHh4KjxsUIiqoA9acOIW9cao=;7:u753lah95ZVUtu73Bxtq3dG57cuC7UUaUkdP2uzw86fosRYdp1sbT28XN3L0eDzYeB32qA1symtTUk8LqsTZe1xvdGpDAxI0hWor9nrgSm6feWQD7O1NppDUy7OWpODX9FBzc0FgrY5gF27HvZI7TfnfSEJRC5i1Mi+srlLRrgdOYbyx9Yq7C93zdPXJebCd SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2016 20:40:27.4371 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR07MB2144 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/12/2016 09:24 AM, Catalin Marinas wrote: > On Thu, May 12, 2016 at 08:27:08AM -0700, David Daney wrote: >> On 05/12/2016 02:49 AM, Catalin Marinas wrote: >>> On Wed, May 11, 2016 at 05:06:13PM -0700, David Daney wrote: >>>> On 05/11/2016 03:39 AM, Catalin Marinas wrote: >> [...] >>>>> >>>>> I wonder whether you could replace the get_mpidr_in_madt() function with >>>>> something like acpi_get_phys_id(). It looks like get_mpidr_in_madt() >>>>> duplicates functionality already available elsewhere. >>>> >>>> I just tried that, and it doesn't work. >>>> >>>> The problem is that this code is being run very early in the boot, and >>>> kmalloc cannot be used. acpi_get_phys_id() and its ilk can only be used >>>> once we have working kmalloc. We need to extract the NUMA information early >>>> like this precisely because it is needed to initializing the slab system >>>> >>>> Notice that we are using early_acpi_os_unmap_memory() et al. in >>>> get_mpidr_in_madt() explicitly for this reason. >>>> >>>> In summary: I don't think we need another revision of this patch, it is like >>>> this for a good reason. >>> >>> Slightly confusing, in another reply you said you are going to address >>> my comment. So, is it doable? >> >> I don't think so. >> >> My previous reply, to the thread in 0/14, was prematurely made with the >> incorrect assumption that it was a simple change. Now, after really digging >> in to the code, and attempting to do as you suggested, I have changed my >> mind. > > Would the snippet below help with avoiding any kmalloc calls? At a quick > look, it seems that it's only map_mat_entry() that ends up using > kmalloc() calls. Alternatively, exporting map_madt_entry() may work as > well. I think making a non-static version of map_madt_entry() is the cleanest solution. That works, so I will send a new version of the patch set that does that instead. David. > > diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c > index 33a38d604630..77af0a7df914 100644 > --- a/drivers/acpi/processor_core.c > +++ b/drivers/acpi/processor_core.c > @@ -152,6 +152,9 @@ static phys_cpuid_t map_mat_entry(acpi_handle handle, int type, u32 acpi_id) > struct acpi_subtable_header *header; > phys_cpuid_t phys_id = PHYS_CPUID_INVALID; > > + if (!acpi_gbl_permanent_mmap) > + return phys_id; > + > if (ACPI_FAILURE(acpi_evaluate_object(handle, "_MAT", NULL, &buffer))) > goto exit; > >