Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2683119imm; Thu, 9 Aug 2018 18:20:49 -0700 (PDT) X-Google-Smtp-Source: AA+uWPwQ3BzXhF/Z/qeGlWlnWet0nogcjBUOSr6S1ceI28FX9fE5581miEQAhPE/pGoTn3prfboP X-Received: by 2002:a17:902:bd44:: with SMTP id b4-v6mr4143466plx.144.1533864049228; Thu, 09 Aug 2018 18:20:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533864049; cv=none; d=google.com; s=arc-20160816; b=zM77Ti7VmmonVDWcTAh5KUwPjNGvCFRPXU0Evr22rAXgNLw3ZTIbigA7IJ/Q+CrQRv qPpGBUfvrmekTRgJgHUE3xWEbL+Pz7EOp7orTqlQ/rOFjcZKkdmsnmrrJY7F5Fz5iAYz AQKclZtZhhCr8WEW2iIrnP2GMiNr5+KnlFlIBYsShu2UkPVEBrktcvgZoZqYfLvU5LYX ic9omGYIoUx/QF5Lb7s4smCob5ySNOOtSr1PiWT0sSQ/xxM9OrJHhkTFyhP2q43Xaw6X Bs77y2UiTKOg4warV+/BUOMTcBOWSZX85EdSECNkKz69B8satUh3kJLx1kE44Td78GSc tMEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=1WCAjBw692cXj6Dzh0ZxFgujuVuySqTw71U4knSf59c=; b=eY4qTQs8aIYAVSHRIS9I2YZy/VPR+6lBeR61fQ3GovqNbGGF24jAgRdE1c+SYmyGgU 5ZWtCuiCY3tGbGTjFN/C55bRqo9JN0mZXZafxCVbKMrWzvf61mOHwhRreDQGXI/yRVgv AHKHkrI0O691/hAryLU7WBEVapuoDjsXBK2KpsaJnyB922HReYpcl2mGcejp3UsPO98G EuObASBklScDyz4ztBo6IJxa20q7st430vo2NpFShzK4STjoNMxErE4FtA2Fu9oWWTHT uC1FmtTUnacVj8WUnywfohWCjyEFi+uYV7Nl1p8EncuWi6kioDgbPKzduX+H/JgE8+5B 4dQA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l21-v6si7485740pgo.272.2018.08.09.18.20.31; Thu, 09 Aug 2018 18:20:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727058AbeHJDjy (ORCPT + 99 others); Thu, 9 Aug 2018 23:39:54 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:46126 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726961AbeHJDjy (ORCPT ); Thu, 9 Aug 2018 23:39:54 -0400 Received: from localhost.localdomain (c-24-4-125-7.hsd1.ca.comcast.net [24.4.125.7]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 8294D9D3; Fri, 10 Aug 2018 01:12:25 +0000 (UTC) Date: Thu, 9 Aug 2018 18:12:24 -0700 From: Andrew Morton To: Rashmica Gupta Cc: toshi.kani@hpe.com, tglx@linutronix.de, bp@suse.de, brijesh.singh@amd.com, thomas.lendacky@amd.com, jglisse@redhat.com, gregkh@linuxfoundation.org, baiyaowei@cmss.chinamobile.com, dan.j.williams@intel.com, mhocko@suse.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz, malat@debian.org, bhelgaas@google.com, osalvador@techadventures.net, yasu.isimatu@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rppt@linux.vnet.ibm.com Subject: Re: [PATCH v3] resource: Merge resources on a node when hot-adding memory Message-Id: <20180809181224.0b7417e51215565dbda9f665@linux-foundation.org> In-Reply-To: <20180809025409.31552-1-rashmica.g@gmail.com> References: <20180809025409.31552-1-rashmica.g@gmail.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Aug 2018 12:54:09 +1000 Rashmica Gupta wrote: > When hot-removing memory release_mem_region_adjustable() splits > iomem resources if they are not the exact size of the memory being > hot-deleted. Adding this memory back to the kernel adds a new > resource. > > Eg a node has memory 0x0 - 0xfffffffff. Offlining and hot-removing > 1GB from 0xf40000000 results in the single resource 0x0-0xfffffffff being > split into two resources: 0x0-0xf3fffffff and 0xf80000000-0xfffffffff. > > When we hot-add the memory back we now have three resources: > 0x0-0xf3fffffff, 0xf40000000-0xf7fffffff, and 0xf80000000-0xfffffffff. > > Now if we try to remove some memory that overlaps these resources, > like 2GB from 0xf40000000, release_mem_region_adjustable() fails as it > expects the chunk of memory to be within the boundaries of a single > resource. > > This patch adds a function request_resource_and_merge(). This is called > instead of request_resource_conflict() when registering a resource in > add_memory(). It calls request_resource_conflict() and if hot-removing is > enabled (if it isn't we won't get resource fragmentation) we attempt to > merge contiguous resources on the node. What is the end-user impact of this patch? Do you believe the fix should be merged into 4.18? Backporting into -stable kernels? If so, why? Thanks.