linux-kernel - Re: slow boot with 7fef431be9c9 ("mm/page_alloc: place pages to tail in __free_pages

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: <9e869214-7a3b-e86d-4832-7117f7c6090f@redhat.com>
Date:   Tue, 16 Mar 2021 10:08:10 +0100
From:   David Hildenbrand <david@...hat.com>
To:     "Liang, Liang (Leo)" <Liang.Liang@....com>,
        Mike Rapoport <rppt@...ux.ibm.com>
Cc:     "Deucher, Alexander" <Alexander.Deucher@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        amd-gfx list <amd-gfx@...ts.freedesktop.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Huang, Ray" <Ray.Huang@....com>,
        "Koenig, Christian" <Christian.Koenig@....com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        George Kennedy <george.kennedy@...cle.com>
Subject: Re: slow boot with 7fef431be9c9 ("mm/page_alloc: place pages to tail
 in __free_pages_core()")

On 16.03.21 09:58, Liang, Liang (Leo) wrote:
> [AMD Public Use]
> 
> Hi David,
> 
> root@...u-Chachani:~# cat /proc/mtrr
> reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
> reg01: base=0x0ffe00000 ( 4094MB), size=    2MB, count=1: write-protect
> reg02: base=0x100000000 ( 4096MB), size=   16MB, count=1: write-protect

^ there it is

https://wiki.osdev.org/MTRR

"Reads allocate cache lines on a cache miss. All writes update main memory.

Cache lines are not allocated on a write miss. Write hits invalidate the 
cache line and update main memory. "

AFAIU, writes completely bypass caches and store directly to main 
mamory. If there are cache lines from a previous read, they are 
invalidated. So I think especially slow will be read(addr), write(addr), 
read(addr), ... which is what we have in the kstream benchmark.

The question is:

who sets this up without owning the memory?
Is the memory actually special/slow or is that setting wrong?
Buggy firmware/BIOS?
Buggy device driver?

> reg03: base=0x0ffde0000 ( 4093MB), size=  128KB, count=1: write-protect
> reg04: base=0x0ff000000 ( 4080MB), size=  512KB, count=1: write-protect

-- 
Thanks,

David / dhildenb