linux-kernel - Re: [PATCH v3 0/9] mm: introduce Designated Movable Blocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e62b0abb-d728-cd22-f58f-a1bd415289c7@gmail.com>
Date:   Wed, 4 Jan 2023 11:10:42 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Mel Gorman <mgorman@...e.de>, Doug Berger <opendmb@...il.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Jonathan Corbet <corbet@....net>,
        Mike Rapoport <rppt@...nel.org>,
        "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>,
        Muchun Song <songmuchun@...edance.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...e.com>,
        KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        David Hildenbrand <david@...hat.com>,
        Oscar Salvador <osalvador@...e.de>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH v3 0/9] mm: introduce Designated Movable Blocks

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