From: Florian Fainelli <f.fainelli@gmail.com>
To: Mel Gorman <mgorman@suse.de>, Doug Berger <opendmb@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>, Mike Rapoport <rppt@kernel.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Randy Dunlap <rdunlap@infradead.org>,
Damien Le Moal <damien.lemoal@opensource.wdc.com>,
Muchun Song <songmuchun@bytedance.com>,
Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@suse.com>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mike Kravetz <mike.kravetz@oracle.com>,
David Hildenbrand <david@redhat.com>,
Oscar Salvador <osalvador@suse.de>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v3 0/9] mm: introduce Designated Movable Blocks
Date: Wed, 4 Jan 2023 11:10:42 -0800 [thread overview]
Message-ID: <e62b0abb-d728-cd22-f58f-a1bd415289c7@gmail.com> (raw)
In-Reply-To: <20230104153724.mormtuefwaiojvqt@suse.de>
On 1/4/23 07:43, Mel Gorman wrote:
[snip]
>> What is of interest to Broadcom customers is to better distribute user space
>> accesses across each memory controller to improve the bandwidth available to
>> user space dominated work flows. With no ZONE_MOVABLE, the BCM7278 SoC with
>> 1GB of memory on each memory controller will place the 1GB on the low
>> address memory controller in ZONE_DMA and the 1GB on the high address memory
>> controller in ZONE_NORMAL. With this layout movable allocation requests will
>> only fallback to the ZONE_DMA (low memory controller) once the ZONE_NORMAL
>> (high memory controller) is sufficiently depleted of free memory.
>>
>> Adding ZONE_MOVABLE memory above ZONE_NORMAL with the current movablecore
>> behavior does not improve this situation other than forcing more kernel
>> allocations off of the high memory controller. User space allocations are
>> even more likely to be on the high memory controller.
>>
>
> But it's a weak promise that interleaving will happen. If only a portion
> of ZONE_MOVABLE is used, it might still be all on the same channel. This
> might improve over time if enough memory was used and the system was up
> for long enough.
It is indeed a weak promise for user-space allocations out of
ZONE_MOVABLE, however the other consumer of the DMB region is a kernel
driver (typically a video decoder engine) which is directly tied to a
specific memory controller/DMB region. For the kernel driver using the
DMB region there is a hard guarantee from the kernel that it gets memory
from a specific PFN range mapping directly to the desired memory
controller and thus it is meeting the desired bandwidth
allocation/deadlines/bursts etc.
We care about both sides of the coin, though we acknowledge that
"controlling" where user-space allocations are coming from such that
they be steered towards a specific memory controller is a much harder
task and so having some amount of non-determinism is acceptable here.
--
Florian
next prev parent reply other threads:[~2023-01-04 19:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 21:53 [PATCH v3 0/9] mm: introduce Designated Movable Blocks Doug Berger
2022-10-20 21:53 ` [PATCH v3 1/9] lib/show_mem.c: display MovableOnly Doug Berger
2022-10-20 21:53 ` [PATCH v3 2/9] mm/page_alloc: calculate node_spanned_pages from pfns Doug Berger
2022-10-20 21:53 ` [PATCH v3 3/9] mm/page_alloc: prevent creation of empty zones Doug Berger
2022-10-20 21:53 ` [PATCH v3 4/9] mm/page_alloc.c: allow oversized movablecore Doug Berger
2022-10-20 21:53 ` [PATCH v3 5/9] mm/page_alloc: introduce init_reserved_pageblock() Doug Berger
2022-10-20 21:53 ` [PATCH v3 6/9] memblock: introduce MEMBLOCK_MOVABLE flag Doug Berger
2022-10-20 21:53 ` [PATCH v3 7/9] mm/dmb: Introduce Designated Movable Blocks Doug Berger
2022-10-20 21:53 ` [PATCH v3 8/9] mm/page_alloc: make alloc_contig_pages DMB aware Doug Berger
2022-10-20 21:53 ` [PATCH v3 9/9] mm/page_alloc: allow base for movablecore Doug Berger
2022-10-26 10:55 ` [PATCH v3 0/9] mm: introduce Designated Movable Blocks Mel Gorman
2022-10-26 11:11 ` David Hildenbrand
2022-10-26 12:02 ` Mel Gorman
2022-11-02 22:33 ` Doug Berger
2022-11-18 17:05 ` Mel Gorman
2022-12-15 0:17 ` Doug Berger
2023-01-04 15:43 ` Mel Gorman
2023-01-04 19:10 ` Florian Fainelli [this message]
2023-01-19 22:33 ` Doug Berger
2023-01-03 23:43 ` Florian Fainelli
2023-01-04 15:56 ` David Hildenbrand
2023-01-04 19:00 ` Florian Fainelli
2023-01-05 13:29 ` David Hildenbrand
2023-04-18 20:09 ` Florian Fainelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e62b0abb-d728-cd22-f58f-a1bd415289c7@gmail.com \
--to=f.fainelli@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=damien.lemoal@opensource.wdc.com \
--cc=david@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mike.kravetz@oracle.com \
--cc=opendmb@gmail.com \
--cc=osalvador@suse.de \
--cc=paulmck@kernel.org \
--cc=quic_neeraju@quicinc.com \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).