From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34B28C46CD4 for ; Wed, 27 Dec 2023 06:30:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAB7A8D0002; Wed, 27 Dec 2023 01:30:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A5D838D0001; Wed, 27 Dec 2023 01:30:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 923738D0002; Wed, 27 Dec 2023 01:30:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7D31B8D0001 for ; Wed, 27 Dec 2023 01:30:52 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 576CAA06F3 for ; Wed, 27 Dec 2023 06:30:52 +0000 (UTC) X-FDA: 81611625144.17.C517224 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 98F74140005 for ; Wed, 27 Dec 2023 06:30:50 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EmYqOqxr; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703658650; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=bDnfvcUIpsjThy41UIH9fHfUKNCRgigj0+IU6wD8T1M=; b=zp7X1IhE7u8Ow+Jx5+yABbExqCKLjb00Yjld7ebmKYs+xHAPTwnAGs+QyJQ7eTnDG5Gokt EMIrYAsHvur2uuIad92mcYeNmg7ovd4Wc8zelO9LFOnTJKrGJiEHrgij1tDwFWi6DxXG4D GrrN/jv1Fhmx6TWNViqBrxtvB9Sulsw= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=EmYqOqxr; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf23.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703658650; a=rsa-sha256; cv=none; b=YDAGoNgquRwt9rUzx0KbcFcnuJQWq1S/lhSwLw1FRrrog0N8WFUZjKvzGXFcUE/5zXaNsx mXzpKGjPqXS5T0WWpjo49z6wcD0Xqx3r2TtZcLpkTKmJC2jM2inbnWHl9V868Kos0LcoiB OHSqnb8EOJfJxa6TcmZlVmv4tn1+KYE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 89BA660EDD; Wed, 27 Dec 2023 06:30:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C76C4C433C8; Wed, 27 Dec 2023 06:30:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703658649; bh=xisIDCIwb1thUnMDfN6RI2xI3tEtbg2i85Ot8u3PO90=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EmYqOqxrIF2SJzYdpvLVaEYpHNzfXsyanfOUXwI3HQV5PbXstYGqbw6kKK0scboRQ QGfQQAOtcKCDEw6koehan41/nK1mXPdTEXaEBRSzJ68Qp9NaNPIyWCxHfalcvOse8C eQfzdXEJ2EAd+IsaCe1pL6wQ6vmjUG0z/7R/+WJx9bzzR2nQ7fiQjiA7kEBJ0Rx414 nt3KQnojqCqCLioJ/qWxbhJ8x4aetmzHMQ9Crx1uq8K1HX90dsWTHlCUAkbD9KjjbW Jn6KqWHN/84vbdvbjzxExCBR0N8oO9OaeK2Mjxc6SwXEphzQfBaukZ/BxOmV6N+ACL fQSz4GMUSko+w== Date: Wed, 27 Dec 2023 08:30:34 +0200 From: Mike Rapoport To: Kefeng Wang Cc: Andrew Morton , linux-mm@kvack.org Subject: Re: [PATCH] mm: remove unnecessary ia64 code and comment Message-ID: References: <20231222070203.2966980-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231222070203.2966980-1-wangkefeng.wang@huawei.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 98F74140005 X-Stat-Signature: 4nw99oehju7mbikuj1iuncotqujr3su6 X-Rspam-User: X-HE-Tag: 1703658650-709484 X-HE-Meta: U2FsdGVkX18zdKYGB3vTczlyOP/FrVEeasHGCCEsSC+oDc4k59T+xB2lZR2rMQsJxAUGDjs8TQtuzLJn39oiwNoDbwAHrxz2liLxtBp9R4zZuA/nH8ZnZkhxRXkC2oSTzPXu8GyB1HWH1Aqp1w/hypXI0syv1elRVaVOIDuPc0G7Dul7VKjaBG/mYdNXzkrzUmt/g4aZs8vYTivfDm5iODFqh7Vt7DCe1x4GMe6/iui9utA5QGkAHVfWVk3TQ7DA/C2gm0qS9eiCI9wKBZDn8XROe0N+aonYvcTZA1nIjn3h2Ki1Rq/KlnyHC8IGK2yxLS/u0tCKXj52hFXbOF0sATloEdOJws5ioUSRdB91NOwcF3d/sF51RdtcNpnKNDeYfeWoefWqzWf8NXD7UzEMSdv0ydSZlNztW1QRrAiz06p94OzZ2PFDqjRiv+qBlFGUdvhNNBGmAubOBbsiw/tSU6WZDr+zYWN0FnCmhDJyB7Ilbra8a7CWVtIHYd2i1fyHb0KJrn9Q7etIrKsHtXV6+SxJB99QBOwJOgyV2+CusFjRHseHBYI8qtDnD3gGgPQt/WvqSeGBPXuOqj6gS2Lq7gxsWr+BCRlfvRQBSJfhSmYJDLlAsGbncelU1ifJmpRfMZx/jQRc3K8b9LPWARz2QaLBhvG/RqzVIXdHx4vRloEWtDtCNWEq9CvNl4bOB+5r9OlBq8UEaa4YaceEqEdl2eX/JV3ecB7cP+++xkpjIZiZ6TX6MSlYs85WTmDJotEA2quYQEEg0EX24rEXJhVva5Lb5XEunngzpssatehCq/Jc31fRUaWjooXOtAOGkt7L0jsPYdIO3WnTACCLrseLyM2aXxs2dOxeX7f8Vs+RDguHVkFwyrehV1sXgy9AWklDBlBp68PcyFerYObzK+J8KxxckveY3VRa6moO/UdDnmnkHsThmk9mcWeLPzE4elgtCHRPnd+W5rbNdjjLgch nz2Nvyap szf4iHgQQCx9QZBTivymFvp3ZgvLxTj7vmS5+i+VtfX1trCpsKRQIY7pBeP9sNSuq8vHwJK8wGGFvHRCjxkrIYBszNsySf8DQyuM/xYRap4vg5/6y9/6hw04nqZMdl0sQK0WJiahq4jyp3I4wDXb8GbYHgKgoUz9OEVjnK1Zu7DDyyxz1NvjlGKLMR6d5sAIU0/p6FrgaTzge+FkdcpWCByRRgvzzvHAJR+PJ93vEin5Dl1ZwlECK36SfPkGzPl0/iCJzLzXLTfk/hHU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Dec 22, 2023 at 03:02:03PM +0800, Kefeng Wang wrote: > IA64 has gone with commit cf8e8658100d ("arch: Remove > Itanium (IA-64) architecture"), remove unnecessary ia64 > special mm code and comment too. > > Signed-off-by: Kefeng Wang Reviewed-by: Mike Rapoport (IBM) > --- > mm/Kconfig | 2 +- > mm/memory.c | 4 +--- > mm/mm_init.c | 48 +++++++++++++++++++----------------------------- > mm/page_owner.c | 1 - > 4 files changed, 21 insertions(+), 34 deletions(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 7824eeb53f7a..a6e1c51959c0 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -732,7 +732,7 @@ config DEFAULT_MMAP_MIN_ADDR > from userspace allocation. Keeping a user from writing to low pages > can help reduce the impact of kernel NULL pointer bugs. > > - For most ia64, ppc64 and x86 users with lots of address space > + For most ppc64 and x86 users with lots of address space > a value of 65536 is reasonable and should cause no problems. > On arm and other archs it should not be higher than 32768. > Programs which use vm86 functionality or have some need to map > diff --git a/mm/memory.c b/mm/memory.c > index 716648268fed..86ca40a3f681 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -123,9 +123,7 @@ static bool vmf_orig_pte_uffd_wp(struct vm_fault *vmf) > /* > * A number of key systems in x86 including ioremap() rely on the assumption > * that high_memory defines the upper bound on direct map memory, then end > - * of ZONE_NORMAL. Under CONFIG_DISCONTIG this means that max_low_pfn and > - * highstart_pfn must be the same; there must be no gap between ZONE_NORMAL > - * and ZONE_HIGHMEM. > + * of ZONE_NORMAL. > */ > void *high_memory; > EXPORT_SYMBOL(high_memory); > diff --git a/mm/mm_init.c b/mm/mm_init.c > index ac3d911c34fd..2390dca94d70 100644 > --- a/mm/mm_init.c > +++ b/mm/mm_init.c > @@ -1467,8 +1467,7 @@ void __init set_pageblock_order(void) > > /* > * Assume the largest contiguous order of interest is a huge page. > - * This value may be variable depending on boot parameters on IA64 and > - * powerpc. > + * This value may be variable depending on boot parameters on powerpc. > */ > pageblock_order = order; > } > @@ -1629,8 +1628,8 @@ void __init *memmap_alloc(phys_addr_t size, phys_addr_t align, > #ifdef CONFIG_FLATMEM > static void __init alloc_node_mem_map(struct pglist_data *pgdat) > { > - unsigned long __maybe_unused start = 0; > - unsigned long __maybe_unused offset = 0; > + unsigned long start, offset, size, end; > + struct page *map; > > /* Skip empty nodes */ > if (!pgdat->node_spanned_pages) > @@ -1638,33 +1637,24 @@ static void __init alloc_node_mem_map(struct pglist_data *pgdat) > > start = pgdat->node_start_pfn & ~(MAX_ORDER_NR_PAGES - 1); > offset = pgdat->node_start_pfn - start; > - /* ia64 gets its own node_mem_map, before this, without bootmem */ > - if (!pgdat->node_mem_map) { > - unsigned long size, end; > - struct page *map; > - > - /* > - * The zone's endpoints aren't required to be MAX_ORDER > - * aligned but the node_mem_map endpoints must be in order > - * for the buddy allocator to function correctly. > - */ > - end = pgdat_end_pfn(pgdat); > - end = ALIGN(end, MAX_ORDER_NR_PAGES); > - size = (end - start) * sizeof(struct page); > - map = memmap_alloc(size, SMP_CACHE_BYTES, MEMBLOCK_LOW_LIMIT, > - pgdat->node_id, false); > - if (!map) > - panic("Failed to allocate %ld bytes for node %d memory map\n", > - size, pgdat->node_id); > - pgdat->node_mem_map = map + offset; > - } > - pr_debug("%s: node %d, pgdat %08lx, node_mem_map %08lx\n", > - __func__, pgdat->node_id, (unsigned long)pgdat, > - (unsigned long)pgdat->node_mem_map); > -#ifndef CONFIG_NUMA > /* > - * With no DISCONTIG, the global mem_map is just set as node 0's > + * The zone's endpoints aren't required to be MAX_ORDER > + * aligned but the node_mem_map endpoints must be in order > + * for the buddy allocator to function correctly. > */ > + end = ALIGN(pgdat_end_pfn(pgdat), MAX_ORDER_NR_PAGES); > + size = (end - start) * sizeof(struct page); > + map = memmap_alloc(size, SMP_CACHE_BYTES, MEMBLOCK_LOW_LIMIT, > + pgdat->node_id, false); > + if (!map) > + panic("Failed to allocate %ld bytes for node %d memory map\n", > + size, pgdat->node_id); > + pgdat->node_mem_map = map + offset; > + pr_debug("%s: node %d, pgdat %08lx, node_mem_map %08lx\n", > + __func__, pgdat->node_id, (unsigned long)pgdat, > + (unsigned long)pgdat->node_mem_map); > +#ifndef CONFIG_NUMA > + /* the global mem_map is just set as node 0's */ > if (pgdat == NODE_DATA(0)) { > mem_map = NODE_DATA(0)->node_mem_map; > if (page_to_pfn(mem_map) != pgdat->node_start_pfn) > diff --git a/mm/page_owner.c b/mm/page_owner.c > index e7eba7688881..040dbf26a986 100644 > --- a/mm/page_owner.c > +++ b/mm/page_owner.c > @@ -121,7 +121,6 @@ static noinline depot_stack_handle_t save_stack(gfp_t flags) > * Sometimes page metadata allocation tracking requires more > * memory to be allocated: > * - when new stack trace is saved to stack depot > - * - when backtrace itself is calculated (ia64) > */ > if (current->in_page_owner) > return dummy_handle; > -- > 2.27.0 > > -- Sincerely yours, Mike.