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 B879BC5479D for ; Tue, 3 Jan 2023 23:43:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B0548E0002; Tue, 3 Jan 2023 18:43:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 25FD18E0001; Tue, 3 Jan 2023 18:43:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1287E8E0002; Tue, 3 Jan 2023 18:43:32 -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 02FF48E0001 for ; Tue, 3 Jan 2023 18:43:32 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D0A7240582 for ; Tue, 3 Jan 2023 23:43:31 +0000 (UTC) X-FDA: 80315117022.23.B0E68EC Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf19.hostedemail.com (Postfix) with ESMTP id 1F4021A0003 for ; Tue, 3 Jan 2023 23:43:29 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=duJsi04e; spf=pass (imf19.hostedemail.com: domain of f.fainelli@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=f.fainelli@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672789410; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jj0THqUyq0c9epY5uG5zGPtVyHSYwFiciPvLTVvEv/w=; b=vpOIgZiT5m3B0+sx4HulhTUi2ARAJ8mNiGPle9Fg3sREMvWPrvi74q30U9Zr/Agya9uWNT ey7ZIwRESFsCtbcix5EzsrhiifAg8jLLIbgAHhddw5fVGutg2DfxEh/2DvaGbprtsfyKk/ LjwvDBO4/uS90+z45+paZwjAwlRayMs= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=duJsi04e; spf=pass (imf19.hostedemail.com: domain of f.fainelli@gmail.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=f.fainelli@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672789410; a=rsa-sha256; cv=none; b=tDvP08S9NNLPlGOXxsEixjQsh4sXVDxF1cBO8sEYGZlnd/XKdBly0Eg/X4BOB1tIo5ihQy nABc/hwNB3eK1DNVgpWtMcCgYlxGQ7cIqOkjCzP7CHBz6CeDlInVfTjlo8Y3JffJbuNcbk +BA2aiXyj0rrvMmYNnGMJortYNYaosg= Received: by mail-pj1-f47.google.com with SMTP id j8-20020a17090a3e0800b00225fdd5007fso23084357pjc.2 for ; Tue, 03 Jan 2023 15:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=jj0THqUyq0c9epY5uG5zGPtVyHSYwFiciPvLTVvEv/w=; b=duJsi04eWthF6rWNroS+QEdDhLdex1ey+UGS94bf9ypty0LR1wgoT79gQ86UNYItis XfH8CCtqsO921bjm50mtLtQczyqysCKVQEsrugxsRY9MC43/Prw3dDAiHt+4Y4TXsci3 SiQErcO8jIBsek0QRCBQfEps5sGJJNMXLHAtBudMKPqYFXbmamx7iDtvGaDHMCjMwOzq R1isTj/48apNsvqCdHjRy8bSqzHgMEG4o/dhKA0HDKtauRpHTKZjjb5H7wNuphgF+r7j 52t9Oz565sXmQP2GA6zetiaL0nlC9TlqGqRFONgv4W6vrsaHkwE5N7ySHloPrGzywqib AuRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jj0THqUyq0c9epY5uG5zGPtVyHSYwFiciPvLTVvEv/w=; b=K8aDG1LfxyHCd/wC442cHoOGO3JqppIFUYP6vCHkhUpHlctjro6G5gos1Ol0N71mPm mdkLEciQIGYOtzQOjYPnou8OenyiBZx/Ht1nMPhcoI3WeUCG27qcfREjSd3c8s3WQfqz GNJ7ReB4kXKadaHUYbjJI2Fb3k3h5ZDkUEmGYSd8xvc1OeohizcLPElFlIRcny4zq8/3 Vp1vSiVAOIRZqfM7ubDKwCTEhRHrJH/dMqGaTIBPkFXpy8peB+WG5NjQAf4j0/Xx2WwW 6AQCMSpIOfpazMCoxz03QEywnI4mtHIdzpPoksFTT9d/RDaoroGpmQsch4fiL+YKcnYn Flyw== X-Gm-Message-State: AFqh2kqVo+rpGsFSgfOAOMHsiHmQ3dAxPX/0HVaVUju+i/SlynNlD+c7 aqjqHN2V5fpMeuyPNZciF/U= X-Google-Smtp-Source: AMrXdXsTITGN+Arz5Oik7NboYEhGg3E9lBL4TJ91XPIYhDuocQ6FRmjng/u62G7S/fn1rWxSVpySrA== X-Received: by 2002:a17:90a:4311:b0:219:e002:1ba3 with SMTP id q17-20020a17090a431100b00219e0021ba3mr49186612pjg.9.1672789408879; Tue, 03 Jan 2023 15:43:28 -0800 (PST) Received: from [10.67.48.245] ([192.19.223.252]) by smtp.googlemail.com with ESMTPSA id t6-20020a17090a5d8600b00219752c8ea5sm19078184pji.37.2023.01.03.15.43.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Jan 2023 15:43:28 -0800 (PST) Message-ID: Date: Tue, 3 Jan 2023 15:43:24 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v3 0/9] mm: introduce Designated Movable Blocks Content-Language: en-US To: Doug Berger , Andrew Morton , Mel Gorman , David Hildenbrand Cc: Jonathan Corbet , Mike Rapoport , Borislav Petkov , "Paul E. McKenney" , Neeraj Upadhyay , Randy Dunlap , Damien Le Moal , Muchun Song , Vlastimil Babka , Johannes Weiner , Michal Hocko , KOSAKI Motohiro , Mike Kravetz , Oscar Salvador , Joonsoo Kim , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20221020215318.4193269-1-opendmb@gmail.com> From: Florian Fainelli In-Reply-To: <20221020215318.4193269-1-opendmb@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1F4021A0003 X-Stat-Signature: yhua3yx1jhqxcuhixd141jjkzmi9z4gb X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1672789409-59036 X-HE-Meta: U2FsdGVkX1+cArSg2oY5YVNi+SfaweavWnhOq6AoBLNDaCyzUPw+gVAx+3vQSUMXvLXuIUQfrT8IlDwP8PDiWaEDRzRiCnyHws99hoEuWY3yYeJpJQRRHTMzJXn+p1I6P82YIU3Ae6h5H3v+EtV9KWfuQ4xuBP9S7+5CU94k1xGKnQI2Kd8NCsH9VgS8sIq4Kam2SDQGt7OmTye1kGeePy9Y+Ew8iW/NMsN85XVARgi0kJmEWo57NYHdpwXA8JgnmnbfjieJVYxvRLqliP2wFyu/XJfPziM53Aw2aBpGMkxqk724vTOJOp18J30Ik7KMF892afAhYeqnvPRpz9q3rBpJLZW8xNZ12CEqcs14wdDB3B3Xj7ufgGlIK1pAScjsieZFwH5JtoRT4l3dK0eHStnJX54kVeVNvw5RQM2KxI/MXoLvxyH7cFbUdIn2atwpv/ccBUOPbb3SY62G0hTvW4xaViOyDWESIlffwc9IUqRMzUbLzvJ7eaGYewSbjLkxA3NVopyZrqjaSAJpr6V4VxTbIhJjO9EVPFjXkuOo7VBX/cBm7O3PhihBrqiLBXwaSt+wBIci7kwjRKJ5xB2kx2pf5Rx+Aa187mQuyjOqtFhBET7iXi6urfhReHraUhhsZy5AoNBOPzLP7DKhJ5B8vWL/dEyeKDaRYB5PB5woqvR4GCHekIr5a83vKs07UgFKPd7C4CGkfJcvcM7rDZF8KaEAxxgng9PnqLKQnsevfEb9buNeOMYHn4YmlFqbcEfU9P0hU75P3i/FjWCXrGMBHoE7UOlY1DvOuuIPan694qT0UFsTzpZcqvzJ6y+mjqmGNgPa3pBz9lsuflMADSJb2VdV06oaUhaj+MYSp3BPfT8smGXK1UAQZixdE0oI6tKgN+I2+qiBuYTWHdy2uiPRdAm9IyoqnDJ5IuQTTmv7TlpoyjTvImnZXwyyqOZcZglpbe4d6YMGOFq5YzBz5+u HcOn0v7w CvCjyahx7pwP8SQHdE1IVd4YcjYZKHQZvC74z9D5d0DAUYs+bHBMkGq4t74Mtx18XHKVhP/4phMCf3h7dvALVlc7cxPtvrh4bNlo3s3AcORm1OY1l3oOvfvJn5qFrZ4oEbXsn 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: On 10/20/22 14:53, Doug Berger wrote: > MOTIVATION: > Some Broadcom devices (e.g. 7445, 7278) contain multiple memory > controllers with each mapped in a different address range within > a Uniform Memory Architecture. Some users of these systems have > expressed the desire to locate ZONE_MOVABLE memory on each > memory controller to allow user space intensive processing to > make better use of the additional memory bandwidth. > Unfortunately, the historical monotonic layout of zones would > mean that if the lowest addressed memory controller contains > ZONE_MOVABLE memory then all of the memory available from > memory controllers at higher addresses must also be in the > ZONE_MOVABLE zone. This would force all kernel memory accesses > onto the lowest addressed memory controller and significantly > reduce the amount of memory available for non-movable > allocations. > > The main objective of this patch set is therefore to allow a > block of memory to be designated as part of the ZONE_MOVABLE > zone where it will always only be used by the kernel page > allocator to satisfy requests for movable pages. The term > Designated Movable Block is introduced here to represent such a > block. The favored implementation allows extension of the > 'movablecore' kernel parameter to allow specification of a base > address and support for multiple blocks. The existing > 'movablecore' mechanisms are retained. > > BACKGROUND: > NUMA architectures support distributing movablecore memory > across each node, but it is undesirable to introduce the > overhead and complexities of NUMA on systems that don't have a > Non-Uniform Memory Architecture. > > Commit 342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror option") > also depends on zone overlap to support sytems with multiple > mirrored ranges. > > Commit c6f03e2903c9 ("mm, memory_hotplug: remove zone restrictions") > embraced overlapped zones for memory hotplug. > > This commit set follows their lead to allow the ZONE_MOVABLE > zone to overlap other zones. Designated Movable Blocks are made > absent from overlapping zones and present within the > ZONE_MOVABLE zone. > > I initially investigated an implementation using a Designated > Movable migrate type in line with comments[1] made by Mel Gorman > regarding a "sticky" MIGRATE_MOVABLE type to avoid using > ZONE_MOVABLE. However, this approach was riskier since it was > much more instrusive on the allocation paths. Ultimately, the > progress made by the memory hotplug folks to expand the > ZONE_MOVABLE functionality convinced me to follow this approach. > Mel, David, does the sub-thread discussion with Doug help ensuring that all of the context is gathered before getting into a more detailed patch review on a patch-by-patch basis? Eventually we may need a fairly firm answer as to whether the proposed approach has any chance of landing upstream in order to either commit to in subsequent iterations of this patch set, or find an alternative. Thank you! -- Florian