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  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:   Tue, 21 May 2019 09:17:32 -0700
From:   Andy Lutomirski <>
To:     Rick Edgecombe <>
Cc:     LKML <>,
        Peter Zijlstra <>,
        sparclinux <>,
        Linux-MM <>,
        Network Development <>,
        Dave Hansen <>,
        Nadav Amit <>,
        "David S. Miller" <>,
        Rick Edgecombe <>,
        Meelis Roos <>, Borislav Petkov <>,
        Andy Lutomirski <>,
        Ingo Molnar <>
Subject: Re: [PATCH v2 2/2] vmalloc: Remove work as from vfree path

On Mon, May 20, 2019 at 4:39 PM Rick Edgecombe
<> wrote:
> From: Rick Edgecombe <>
> Calling vm_unmap_alias() in vm_remove_mappings() could potentially be a
> lot of work to do on a free operation. Simply flushing the TLB instead of
> the whole vm_unmap_alias() operation makes the frees faster and pushes
> the heavy work to happen on allocation where it would be more expected.
> In addition to the extra work, vm_unmap_alias() takes some locks including
> a long hold of vmap_purge_lock, which will make all other
> VM_FLUSH_RESET_PERMS vfrees wait while the purge operation happens.
> Lastly, page_address() can involve locking and lookups on some
> configurations, so skip calling this by exiting out early when

Hmm.  I would have expected that the major cost of vm_unmap_aliases()
would be the flush, and at least informing the code that the flush
happened seems valuable.  So would guess that this patch is actually a
loss in throughput.


Powered by blists - more mailing lists