From patchwork Thu Nov 17 05:34:24 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 82659 Delivered-To: patch@linaro.org Received: by 10.140.97.165 with SMTP id m34csp561174qge; Wed, 16 Nov 2016 21:36:55 -0800 (PST) X-Received: by 10.99.117.71 with SMTP id f7mr3595784pgn.126.1479361014766; Wed, 16 Nov 2016 21:36:54 -0800 (PST) Return-Path: Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id x5si1514652pfa.210.2016.11.16.21.36.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 21:36:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) client-ip=2001:1868:205::9; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org designates 2001:1868:205::9 as permitted sender) smtp.mailfrom=linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7FM9-0004AX-UJ; Thu, 17 Nov 2016 05:35:29 +0000 Received: from mail-pg0-x22f.google.com ([2607:f8b0:400e:c05::22f]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7FM1-0002xJ-Nv for linux-arm-kernel@lists.infradead.org; Thu, 17 Nov 2016 05:35:24 +0000 Received: by mail-pg0-x22f.google.com with SMTP id p66so87614871pga.2 for ; Wed, 16 Nov 2016 21:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8VQN6X+o5LpIJHkcXc/qwZUTlb2m2wQl69SvVWTjVtQ=; b=FCQ1pHTIJhZbe3ClkfeXKUgRkUsJrl8VmX+9aOETYl8+pWHDkCvV3isIcvbpD08Cab xq3xCvsqI5Xe1Wi2vkHaJUNzTOHy4dsLgbhAd266dDf1iscgIjcSITAOUl1wBCH+epnj 7dFmEPWl60P8dZq1se8hmWKehp0eQB1co3Khk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=8VQN6X+o5LpIJHkcXc/qwZUTlb2m2wQl69SvVWTjVtQ=; b=g+Ro+l/sx8ZobIkXQ5eKjaezIeo2tttVu5UCq0bkGJHMr4R5l51YfoyCQn8cz90Pr7 qBGS58G+i9p08c3Odd5IkBQIZGFbLbSZLILhoGZxXkoE2unwQzZCdxW5x6kgPu3iZHI+ 0gy5WM0SU2V88IvRJAET5TkDuXjNK2cms2ztJ5iwrZ3x9JH5bp+f62zsHnxry6XQl7hk ex8xmfkbCRswa985j341e7p4T8Kj59tQkzB3paZ16g0cBtKfEqKabw/gbCMPViuKFW9m rPA+p8vOiocHcltwvF7u/RMWhVrAsEwQN9AvWw1/qwmUgMTQbgZuW2OQOqcVMo1MU7/4 ZoUA== X-Gm-Message-State: ABUngvcnZCWJEmP98X7iYESBBWBfjh8CsRpNKNzU//03atmkIbUFWa+vC1uCWjTFIQVHYd1H X-Received: by 10.98.36.195 with SMTP id k64mr2182268pfk.126.1479360900019; Wed, 16 Nov 2016 21:35:00 -0800 (PST) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id c8sm2368889pfe.15.2016.11.16.21.34.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 21:34:59 -0800 (PST) Date: Thu, 17 Nov 2016 14:34:24 +0900 From: AKASHI Takahiro To: Will Deacon Subject: Re: [PATCH v27 1/9] memblock: add memblock_cap_memory_range() Message-ID: <20161117022023.GA5704@linaro.org> Mail-Followup-To: AKASHI Takahiro , Will Deacon , Dennis Chen , catalin.marinas@arm.com, akpm@linux-foundation.org, james.morse@arm.com, geoff@infradead.org, bauerman@linux.vnet.ibm.com, dyoung@redhat.com, mark.rutland@arm.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, nd@arm.com References: <20161102044959.11954-1-takahiro.akashi@linaro.org> <20161102045153.12008-1-takahiro.akashi@linaro.org> <20161110172720.GB17134@arm.com> <20161111025049.GG381@linaro.org> <20161111031903.GB15997@arm.com> <20161114055515.GH381@linaro.org> <20161116163015.GM7928@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161116163015.GM7928@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20161116_213521_892135_4D9D1AF9 X-CRM114-Status: GOOD ( 28.20 ) X-Spam-Score: -2.0 (--) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-2.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2607:f8b0:400e:c05:0:0:0:22f listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, geoff@infradead.org, catalin.marinas@arm.com, kexec@lists.infradead.org, linux-mm@kvack.org, james.morse@arm.com, bauerman@linux.vnet.ibm.com, Dennis Chen , akpm@linux-foundation.org, nd@arm.com, dyoung@redhat.com, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patch=linaro.org@lists.infradead.org Will, On Wed, Nov 16, 2016 at 04:30:15PM +0000, Will Deacon wrote: > Hi Akashi, > > On Mon, Nov 14, 2016 at 02:55:16PM +0900, AKASHI Takahiro wrote: > > On Fri, Nov 11, 2016 at 11:19:04AM +0800, Dennis Chen wrote: > > > On Fri, Nov 11, 2016 at 11:50:50AM +0900, AKASHI Takahiro wrote: > > > > On Thu, Nov 10, 2016 at 05:27:20PM +0000, Will Deacon wrote: > > > > > On Wed, Nov 02, 2016 at 01:51:53PM +0900, AKASHI Takahiro wrote: > > > > > > +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size) > > > > > > +{ > > > > > > + int start_rgn, end_rgn; > > > > > > + int i, ret; > > > > > > + > > > > > > + if (!size) > > > > > > + return; > > > > > > + > > > > > > + ret = memblock_isolate_range(&memblock.memory, base, size, > > > > > > + &start_rgn, &end_rgn); > > > > > > + if (ret) > > > > > > + return; > > > > > > + > > > > > > + /* remove all the MAP regions */ > > > > > > + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--) > > > > > > + if (!memblock_is_nomap(&memblock.memory.regions[i])) > > > > > > + memblock_remove_region(&memblock.memory, i); > > > > > > + > > > > > > + for (i = start_rgn - 1; i >= 0; i--) > > > > > > + if (!memblock_is_nomap(&memblock.memory.regions[i])) > > > > > > + memblock_remove_region(&memblock.memory, i); > > > > > > + > > > > > > + /* truncate the reserved regions */ > > > > > > + memblock_remove_range(&memblock.reserved, 0, base); > > > > > > + memblock_remove_range(&memblock.reserved, > > > > > > + base + size, (phys_addr_t)ULLONG_MAX); > > > > > > +} > > > > > > > > > > This duplicates a bunch of the logic in memblock_mem_limit_remove_map. Can > > > > > you not implement that in terms of your new, more general, function? e.g. > > > > > by passing base == 0, and size == limit? > > > > > > > > Obviously it's possible. > > > > I actually talked to Dennis before about merging them, > > > > but he was against my idea. > > > > > > > Oops! I thought we have reached agreement in the thread:http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/442817.html > > > So feel free to do that as Will'll do > > > > OK, but I found that the two functions have a bit different semantics > > in clipping memory range, in particular, when the range [base,base+size) > > goes across several regions with a gap. > > (This does not happen in my arm64 kdump, though.) > > That is, 'limit' in memblock_mem_limit_remove_map() means total size of > > available memory, while 'size' in memblock_cap_memory_range() indicates > > the size of _continuous_ memory range. > > I thought limit was just a physical address, and then No, it's not. > memblock_mem_limit_remove_map operated on the end of the nearest memblock? No, but "max_addr" returned by __find_max_addr() is a physical address and the end address of memory of "limit" size in total. > You could leave the __find_max_addr call in memblock_mem_limit_remove_map, > given that I don't think you need/want it for memblock_cap_memory_range. > > > So I added an extra argument, exact, to a common function to specify > > distinct behaviors. Confusing? Please see the patch below. > > Oh yikes, this certainly wasn't what I had in mind! My observation was > just that memblock_mem_limit_remove_map(limit) does: > > > 1. memblock_isolate_range(limit - limit+ULLONG_MAX) > 2. memblock_remove_region(all non-nomap regions in the isolated region) > 3. truncate reserved regions to limit > > and your memblock_cap_memory_range(base, size) does: > > 1. memblock_isolate_range(base - base+size) > 2, memblock_remove_region(all non-nomap regions above and below the > isolated region) > 3. truncate reserved regions around the isolated region > > so, assuming we can invert the isolation in one of the cases, then they > could share the same underlying implementation. Please see my simplified patch below which would explain what I meant. (Note that the size is calculated by 'max_addr - 0'.) > I'm probably just missing something here, because the patch you've ended > up with is far more involved than I anticipated... I hope that it will meet almost your anticipation. Thanks, -Takahiro AKASHI > > Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Reviewed-by: Will Deacon ===8<=== diff --git a/mm/memblock.c b/mm/memblock.c index 7608bc3..fea1688 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit) (phys_addr_t)ULLONG_MAX); } +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size) +{ + int start_rgn, end_rgn; + int i, ret; + + if (!size) + return; + + ret = memblock_isolate_range(&memblock.memory, base, size, + &start_rgn, &end_rgn); + if (ret) + return; + + /* remove all the MAP regions */ + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--) + if (!memblock_is_nomap(&memblock.memory.regions[i])) + memblock_remove_region(&memblock.memory, i); + + for (i = start_rgn - 1; i >= 0; i--) + if (!memblock_is_nomap(&memblock.memory.regions[i])) + memblock_remove_region(&memblock.memory, i); + + /* truncate the reserved regions */ + memblock_remove_range(&memblock.reserved, 0, base); + memblock_remove_range(&memblock.reserved, + base + size, (phys_addr_t)ULLONG_MAX); +} + void __init memblock_mem_limit_remove_map(phys_addr_t limit) { - struct memblock_type *type = &memblock.memory; phys_addr_t max_addr; - int i, ret, start_rgn, end_rgn; if (!limit) return; @@ -1529,19 +1555,7 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit) if (max_addr == (phys_addr_t)ULLONG_MAX) return; - ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX, - &start_rgn, &end_rgn); - if (ret) - return; - - /* remove all the MAP regions above the limit */ - for (i = end_rgn - 1; i >= start_rgn; i--) { - if (!memblock_is_nomap(&type->regions[i])) - memblock_remove_region(type, i); - } - /* truncate the reserved regions */ - memblock_remove_range(&memblock.reserved, max_addr, - (phys_addr_t)ULLONG_MAX); + memblock_cap_memory_range(0, max_addr); } static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)