linux-kernel - Re: [PATCH 0/5] Rewrite Motorola MMU page-table layout

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]

Date:   Thu, 30 Jan 2020 20:31:13 +1300
From:   Michael Schmitz <schmitzmic@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linux/m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Development <linux-kernel@...r.kernel.org>,
        Will Deacon <will@...nel.org>
Subject: Re: [PATCH 0/5] Rewrite Motorola MMU page-table layout

Peter,

Am 30.01.2020 um 08:31 schrieb Peter Zijlstra:
> On Thu, Jan 30, 2020 at 07:52:11AM +1300, Michael Schmitz wrote:
>> Peter,
>>
>> On Thu, Jan 30, 2020 at 12:54 AM Peter Zijlstra <peterz@...radead.org> wrote:
>>>
>>> On Wed, Jan 29, 2020 at 11:49:13AM +0100, John Paul Adrian Glaubitz wrote:
>>>
>>>>> [1] https://wiki.debian.org/M68k/QemuSystemM68k
>>>
>>> Now, if only debian would actually ship that :/
>>>
>>> AFAICT that emulates a q800 which is another 68040 and should thus not
>>> differ from ARAnyM.
>>>
>>> I'm fairly confident in the 040 bits, it's the 020/030 things that need
>>> coverage.
>>
>> I'll take a look - unless this eats up way more kernel memory for page
>> tables, it should still boot on my Falcon.
>
> It should actually be better in most cases I think, since we no longer
> require all 16 pte-tables to map consecutive (virtual) memory.

Not much difference:

              total       used       free     shared    buffers     cached
Mem:         10712      10120        592          0       1860       2276
-/+ buffers/cache:       5984       4728
Swap:      2097144       1552    2095592


vs. vanilla 5.5rc5:
              total       used       free     shared    buffers     cached
Mem:         10716      10104        612          0       1588       2544
-/+ buffers/cache:       5972       4744
Swap:      2097144       1296    2095848

By sheer coincidence, the boot with your patch series happened to run a 
full filesystem check on the root filesystem, so I'd say it got a good 
workout re: paging and swapping (even though it's just a paltry 4 GB).

Haven't tried any VM stress testing yet (not sure what to do for that; 
it's been years since I tried that sort of stuff).

Cheers,

	Michael