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  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:   Fri, 12 Oct 2018 18:54:33 -0700
From:   Daniel Colascione <>
To:     Joel Fernandes <>
Cc:     David Miller <>,,
        linux-kernel <>,, Minchan Kim <>,
        Ramon Pantin <>,,
        Lokesh Gidra <>,
        Michal Hocko <>,
        Andrew Morton <>,,,,,,,,,,,,,,,,,,,,,,,,,
        linux-mm <>,,,,,,,,,,,
        Peter Zijlstra <>,
Subject: Re: [PATCH v2 2/2] mm: speed up mremap by 500x on large regions

I wonder whether it makes sense to expose to userspace somehow whether
mremap is "fast" for a particular architecture. If a feature relies on
fast mremap, it might be better for some userland component to disable
that feature entirely rather than blindly use mremap and end up
performing very poorly. If we're disabling fast mremap when THP is
enabled, the userland component can't just rely on an architecture
switch and some kind of runtime feature detection becomes even more

On Fri, Oct 12, 2018 at 6:44 PM, Joel Fernandes <> wrote:
> On Fri, Oct 12, 2018 at 06:39:45PM -0700, Daniel Colascione wrote:
>> Not 32-bit ARM?
> Well, I didn't want to enable every possible architecture we could in a
> single go. Certainly arm32 can be a follow on enablement as can be other
> architectures. The point of this series is to upstream this feature and
> enable a hand-picked few architectures as a first step.
> thanks,
>  - Joel

Powered by blists - more mailing lists