linux-kernel - Re: [PATCH] mm/vmalloc: reduce the number of lazy_max

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: <20161009192610.GB2718@nuc-i3427.alporthouse.com>
Date:   Sun, 9 Oct 2016 20:26:11 +0100
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Joel Fernandes <joel.opensrc@...il.com>
Cc:     Joel Fernandes <agnel.joel@...il.com>,
        Jisheng Zhang <jszhang@...vell.com>, npiggin@...nel.dk,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mm@...ck.org, rientjes@...gle.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        mgorman@...hsingularity.net, iamjoonsoo.kim@....com,
        Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to
 reduce latency

On Sun, Oct 09, 2016 at 12:00:31PM -0700, Joel Fernandes wrote:
> Ok. So I'll submit a patch with mutex for purge_lock and use
> cond_resched_lock for the vmap_area_lock as you suggested. I'll also
> drop the lazy_max_pages to 8MB as Andi suggested to reduce the lock
> hold time. Let me know if you have any objections.

The downside of using a mutex here though, is that we may be called
from contexts that cannot sleep (alloc_vmap_area), or reschedule for
that matter! If we change the notion of purged, we can forgo the mutex
in favour of spinning on the direct reclaim path. That just leaves the
complication of whether to use cond_resched_lock() or a lock around
the individual __free_vmap_area().
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre