Date:   Wed, 12 Oct 2022 16:38:06 -0700
From:   Doug Berger <opendmb@...il.com>
To:     David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     Jonathan Corbet <corbet@....net>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Frank Rowand <frowand.list@...il.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <songmuchun@...edance.com>,
        Mike Rapoport <rppt@...nel.org>,
        Christoph Hellwig <hch@....de>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Robin Murphy <robin.murphy@....com>,
        Borislav Petkov <bp@...e.de>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Neeraj Upadhyay <quic_neeraju@...cinc.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Zi Yan <ziy@...dia.com>, Oscar Salvador <osalvador@...e.de>,
        Hari Bathini <hbathini@...ux.ibm.com>,
        Kees Cook <keescook@...omium.org>,
        KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
        Mel Gorman <mgorman@...e.de>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-mm@...ck.org, iommu@...ts.linux.dev
Subject: Re: [PATCH 00/21] mm: introduce Designated Movable Blocks

Reordered to (hopefully) improve readability.

On 10/5/2022 11:39 AM, David Hildenbrand wrote:
 > May I ask what the main purpose/use case of DMB is?
The concept of Designated Movable Blocks was conceived to provide a 
common mechanism for different use cases, so identifying the "main" one 
is not so easy. Broadly speaking I would say there are two different but 
compatible objectives that could be used to categorize use cases.

The narrower objective is the ability to locate some "user space 
friendly" memory on each memory controller to make more of the total 
memory bandwidth available to user space processes. The ZONE_MOVABLE 
zone is considered to be "user space friendly" so locating some of it on 
each memory controller would meet this objective. The existing 
'movablecore' kernel parameter allows the balance of kernel/movable 
memory to be adjusted, but movable memory will always be located on the 
highest addressed memory controller. The v2 patch set attempts to focus 
explicitly on the use case of adding a base address to the 'movablecore' 
kernel parameter to support this objective.

The other general objective is to facilitate better reuse/sharing of 
memory. Broadcom Set-Top Box SoCs include video processing devices that 
can require large amounts of memory to perform their functions. 
Historically, memory carve-outs have been used to ensure guaranteed 
availability of memory to meet the requirements of cable television 
customers. The rise of Android TV and Google TV have made the 
inefficiency of memory carve-outs unacceptable.

We have tried to meet the reusability objective with a CMA based 
implementation, but Broadcom customers were unhappy with the 
performance. Efforts to improve the CMA performance led me to Joonsoo's 
efforts to do the same and to the "sticky" MIGRATE_MOVABLE proposal from 
Mel Gorman that I cited. I began working on an implementation of 
Designated Movable Blocks based on that proposal which could be 
characterized as reserving a block of memory, assigning it a new 
"sticky" movable migrate type, and modifying the fast and slow path page 
allocators to handle the new migrate type such that requests for movable 
memory could be satisfied by pages from the blocks and that the migrate 
type of pages in the blocks could not be changed by "fallback" mechanisms.

Both of these objectives require the ability to specify the location of 
a block of memory that can only be used by the Linux kernel page 
allocator to satisfy requests for movable memory. The location is 
relevant because it may need to be on a specific memory controller or it 
may have to satisfy the DMA address range of a specific device. The 
movability is relevant because it improves the availability to user 
space allocations or it allows the data occupying the memory to be moved 
away when the memory is required by the device. The Designated Movable 
Block mechanism was designed to satisfy these requirements and was seen 
as a common mechanism for both objectives.

While learning more about the page allocator implementation, I realized 
that hotplug memory also has these same requirements. The location of 
hotplug memory is determined by the system hardware independent of 
Linux's zone concepts and the data stored on the memory must be movable 
to support the ability to offline the memory before it is unplugged. 
This led me to study the hotplug memory implementation to understand how 
they satisfied these requirements.

I became aware that the "narrower objective" could conceivably be 
satisfied by the hotplug memory capability with a few challenges. First 
the size of hotplug memory sections is a bit course. The current 128MB 
sections on arm64 are not too bad and are far better than the 1GB 
sections that were in place when I first looked at it.

For systems that do not support ACPI there is no clear way to specify 
hotplug memory regions at boot time. When Linux boots an arm64 kernel 
with devicetree the OS attempts to initialize all available memory 
described by the devicetree. Typically this boot memory cannot be 
unplugged to allow it to be plugged into a different zone. A devicetree 
specification of the hardware could intentionally leave holes in its 
memory description to allow for runtime plugging of memory into the 
holes, but this goes against the spirit of a devicetree description of 
the system hardware as it is not representative of what hardware is 
actually present. The 'mem=' kernel parameter can be used to prevent 
Linux from initializing all of the available memory so that memory could 
be hotplugged after boot, but this breaks devicetree mechanisms for 
reserving memory from addresses that might only be populated by hotplug 
after boot.

It also becomes difficult to manage the selection of zones where memory 
is hotplugged. Referring again to the example system with 1GB on MEMC0 
and 1GB on MEMC1 we could boot with 'mem=768M' to leave 256MB 
unpopulated on MEMC0 and all of the memory (1GB) on MEMC1 unpopulated.
If we set the memory_hotplug module parameter online_policy to 
"auto-movable" then adding 256MB at 0x70000000 will put the memory in 
ZONE_MOVABLE as desired. However, we might want to hotplug 768MB at 
0x300000000 into ZONE_NORMAL and 256MB at 0x330000000 into ZONE_MOVABLE. 
The fact that the memory_hotplug parameters are not easily modifiable 
from the kernel modules that are necessary to access the memory_hotplug 
API makes this a difficult dance. I have experimented with a simple 
module exposing hotplug capability to user space and have confirmed as a 
proof of concept that user space can adjust the memory_hotplug 
parameters and use the module to achieve the desired zone population 
with hotplug. The /sys/devices/system/memory/probe control simplifies 
this, but is not enabled on arm64 architectures.

In addition, keeping this memory unplugged until after boot means that 
the memory cannot be used during boot. Kernel boot time reservations are 
a mixed bag. On the one hand they won't land in ZONE_MOVABLE which is 
nice, but in this example they land in ZONE_DMA which can be considered 
a more valuable resource than ZONE_NORMAL. Both of these issues are not 
likely to be of significant consequence, but neither is really desirable.

Finally, just like there are those that may not want to execute a NUMA 
kernel (e.g. Android GKI arm64), there may also be those that don't want 
to include memory hotplug support in their kernel. These things can 
change, but are not always under our control.

If you are aware of solutions to these issues that would make memory 
hotplug a more viable solution for us than DMB I would be happy to know 
them.

These observations led me to design DMB more as an extension of 
'movablecore' than an extension of memory hotplug. However, the 
efficiency of using the ZONE_MOVABLE zone to collect and manage "sticky" 
movable pages in an address independent way without "fallback" (as is 
done by memory hotplug) won me over and I abandoned the idea of 
modifying the fast and slow page allocator paths to support a "sticky" 
movable migrate type. The implementation of DMB was re-conceived to 
preserve the existing 'movablecore' mechanism of creating a dynamic 
ZONE_MOVABLE zone that spans from zone_movable_pfn for each node to the 
end of memory on the node, and adding the ability to designate blocks of 
memory whose pages would be removed from their default zone and placed 
in the ZONE_MOVABLE zone. The span of each ZONE_MOVABLE zone was 
increased to start at the lowest pfn in the zone on the node and 
continue to the end of memory on the node. I also neglected to destroy 
zones that became empty after their pages were moved to ZONE_MOVABLE. 
These last two decisions were a matter of convenience, but I can see 
that they may have created some confusion (based on your questions) so I 
am happy to reconsider them.

 >
 > Would it be sufficient, to specify that hugetlb are allocated from a
 > specific memory area, possible managed by CMA? And then simply providing
 > the application that cares these hugetlb pages? Would you need something
 > that is *not* hugetlb?
 >
 > But even then, how would an application be able to specify that exactly
 > it's allocation will get served from that part of ZONE_MOVABLE? Sure, if
 > you don't reserve any other hugetlb pages, it's easy.
As noted before I actually have very limited visibility into how the 
"narrower objective" is being used by Broadcom customers and how much 
benefit it provides. I believe its current use is probably simply 
opportunistic, but these kinds of improvements to hugetlb allocation 
might be welcomed.

I'd say the hugetlb_cma is similar to what you are describing except 
that it is consolidated rather than being distributed across multiple 
memory areas. Such changes to add benefit to the "narrower objective" 
need not be considered with respect to this patch set. On the other 
hand, the reuse objective of Designated Movable Blocks could be very 
relevant to hugetlb_cma.

>>
>> I agree with Mel Gorman that zones are meant to be about address induced
>> limitations, so using a zone for the purpose of breaking the fallback
>> mechanism of the page allocator is a misuse of the concept. A new
>> migratetype would be more appropriate for representing this change in
>> how fallback should apply to the pageblock because the desired behavior
>> has nothing to do with the address at which the memory is located. It is
>> entirely reasonable to desire "sticky" movable behavior for memory in
>> any zone. Such a solution would be directly applicable to our multiple
>> memory controller use case, and is really how Designated Movable Blocks
>> should be imagined.
> 
> I usually agree with Mel, but not necessarily on that point that it's a 
> misuse of a concept. It's an extension of an existing concept, that 
> doesn't imply it's a misuse. Traditionally, it was about address 
> limitations, yes. Now it's also about allocation types. Sure, there 
> might be other ways to get it done as well.
Yes, I would also agree that when introduced that was the concept, but 
that the extensions made for memory hotplug have enough value to be a 
justified extension of the initial concept. That is exactly why I 
changed my approach.

> 
> I'd compare it to the current use of NUMA nodes: traditionally, it 
> really used to be actual NUMA nodes. Nowadays, it's a mechanism, for 
> example, to expose performance-differented memory, let applications use 
> it via mbind() or have the page allocator dynamically migrate hot/cold 
> pages back and forth according to memory tiering strategies.
You are helping me gain an appreciation for the current extensions of 
the node concept beyond the initial use for NUMA. It does sound useful 
for applications that do want to have that finer control over the 
resources they use.

However, I still believe there is value in the Designated Movable Block 
concept that should be realizable when nodes are not available in the 
kernel config. The implementation I am proposing should not incur a cost 
for those that don't wish to use it.

> 
>>
>> However, I also recognize the efficiency benefits of using a
>> ZONE_MOVABLE zone to manage the pages that have this "sticky" movable
>> behavior. Introducing a new sticky MIGRATE_MOVABLE migratetype adds a
>> new free_list to every free_area which increases the search space and
>> associated work when trying to allocate a page for all callers.
>> Introducing ZONE_MOVABLE reduces the search space by providing an early
>> separation between searches for movable and non-movable allocations. The
>> classic zone restrictions weren't a good fit for multiple memory
>> controllers, but those restrictions were lifted to overcome similar
>> issues with memory_hotplug. It is not that Designated Movable Blocks
>> want to be in ZONE_MOVABLE, but rather that ZONE_MOVABLE provides a
>> convenience for managing the page allocators use of "sticky" movable
>> memory just like it does for memory hotplug. Dumping the memory in
>> Designated Movable Blocks into the ZONE_MOVABLE zone allows an existing
>> mechanism to be reused, reducing the risk of negatively impacting the
>> page allocator behavior.
>>
>> There are some subtle distinctions between Designated Movable Blocks and
>> the existing ZONE_MOVABLE zone. Because Designated Movable Blocks are
>> reserved when created they are protected against any early boot time
>> kernel reservations that might place unmovable allocations in them. The
>> implementation continues to track the zone_movable_pfn as the start of
>> the "classic" ZONE_MOVABLE zone on each node. A Designated Movable Block
>> can overlap any other zone including the "classic" ZONE_MOVABLE zone.
> 
> What exactly to you mean with "overlay" -- I assume you mean that zone 
> span will overlay but it really "belongs" to ZONE_MOVABLE, as indicated 
> by it's struct page metadata.
Yes. If the pages of a DMB are within the span of a zone I am saying it 
overlaps that zone. The pages will only be "present" in the ZONE_MOVABLE 
zone.

>>>>
>>>>>
>>>>> Why do we have to start using ZONE_MOVABLE for them?
>>>> One of the "other opportunities" for Designated Movable Blocks is to
>>>> allow CMA to allocate from a DMB as an alternative. This would allow
>>>> current users to continue using CMA as they want, but would allow users
>>>> (e.g. hugetlb_cma) that are not sensitive to the allocation latency to
>>>> let the kernel page allocator make more complete use (i.e. waste less)
>>>> of the shared memory. ZONE_MOVABLE pageblocks are always 
>>>> MIGRATE_MOVABLE
>>>> so the restrictions placed on MIGRATE_CMA pageblocks are lifted 
>>>> within a
>>>> DMB.
>>>
>>> The whole purpose of ZONE_MOVABLE is that *no* unmovable allocations end
>>> up on it. The biggest difference to CMA is that the CMA *owner* is able
>>> to place unmovable allocations on it.
>> I'm not sure that is a wholly fair characterization (or maybe I just
>> hope that's the case :). I would agree that the Linux page allocator
>> can't place any unmovable allocations on it. I expect that people locate
>> memory in ZONE_MOVABLE for different purposes. For example, the memory
>> hotplug users ostensibly place memory there so that any data on the hot
>> plugged memory can be moved off of the memory prior to it being hot
>> unplugged. Unplugging the memory removes the memory from the
>> ZONE_MOVABLE zone, but it is not materially different from allocating
>> the memory for a different purpose (perhaps in a different machine).
> 
> Well, memory offlining is the one operation that evacuates memory) and 
> makes sure it cannot be allocated anymore (possibly with the intention 
> of removing that memory from the system). Sure, you can call it a fake 
> allocation, but there is a more fundamental difference compared to 
> random subsystems placing unmovable allocations there.
For the record, I am not offended by your use of the word "random" in 
that statement. I was once informed I unintentionally offended someone 
by using the term "arbitrary" in a similar way ;).

Any such unmovable allocation should be made with intent and with 
authority to do so. The memory hotunplug is an example (perhaps a 
singular one) of a subsystem that can do so with intent and authority. 
Randomness plays no role.

"Ownership" of a DMB would imply authority and such an owner should be 
presumed to be acting with intent. So the mechanics of ownership and 
methods should be formalized before the general objective of reuse of 
DMBs for non-movable purposes (e.g. hugetlb_cma, device driver, ...) is 
allowed. This is why that objective has been deferred with the hope that 
users that may have an interest in this objective can propose their 
favored mechanism.

The "narrower objective" expressed in my v2 submission (i.e. movablecore 
with base address) does not make any non-movable allocations so explicit 
ownership is not necessary. Maybe whoever provided the 'movablecore' 
parameter is the implied owner, but it doesn't much matter in this case. 
Conceptually such a DMB could be hotunplugged, but that would be unexpected.

> 
>>
>> Conceptually, allowing a CMA allocator to operate on a Designated
>> Movable Block of memory that it *owns* is also removing that memory from
>> the ZONE_MOVABLE zone. Issues of ownership should be addressed which is
>> why these "other opportunities" are being deferred for now, but I do not
>> believe such use is unreasonable. Again, Designated Movable Blocks are
>> only allowed in boot memory so there shouldn't be a conflict with memory
>> hotplug. I believe the same would apply for hugetlb_cma.
>>>
>>> Using ZONE_MOVABLE for unmovable allocations (hugetlb_cma) is not
>>> acceptable as is.
>>>
>>> Using ZONE_MOVABLE in different context and calling it DMB is very
>>> confusing TBH.
>> Perhaps it is more helpful to think of a Designated Movable Block as a
>> block of memory whose migratetype is not allowed to be changed from
>> MIGRATE_MOVABLE (i.e. "sticky" migrate movable). The fact that
> 
> I think that such a description might make the feature easier to grasp. 
> Although I am not sure yet if DMB as proposed is rather a hack to avoid 
> introducing real sticky movable blocks (sorry, I'm just trying to 
> connect the dots and there is a lot of complexity involved) or actually 
> a clean design. Messing with zones and memblock always implies 
> complexity :)
I very much appreciate your efforts to make sense of this. I am not 
certain whether that OR is INCLUSIVE or EXCLUSIVE. I would say that the 
implementation attempts to reuse the clean design of ZONE_MOVABLE (as 
extended by memory hotplug) to provide the management of "sticky" 
movable blocks that may overlap/overlay other zones. Doing so makes it 
unnecessary to provide an otherwise redundant implementation of "sticky" 
movable blocks that would likely degrade the performance of page 
allocations from zones other than ZONE_MOVABLE, even when no "sticky" 
movable blocks exist in the system.

> 
>> ZONE_MOVABLE is being used to achieve that is an implementation detail
>> for this commit set. In the same way that memory hotplug is the concept
>> of adding System RAM during run time, but placing it in ZONE_MOVABLE is
>> an implementation detail to make it easier to unplug.
> 
> Right, but there we don't play any tricks: it's just ZONE_MOVABLE 
> without any other metadata pointing out ownership. Maybe that's what you 
> are trying to describe here: A DMB inside ZONE_MOVABLE implies that 
> there is another owner and that even memory offlining should fail.
Now why didn't I just say that in the first place :). The general 
objective of reuse is inspired by CMA which has implied/explicit 
ownership and as noted above DMB needs ownership to meet this objective 
as well.

Thanks for your patience and helping me attempt to communicate this more 
clearly.
-Doug

Powered by blists - more mailing lists