linux-kernel - Re: [PATCH] z3fold: use per-cpu unbuddied lists

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 2 Aug 2017 16:07:16 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Vitaly Wool <vitalywool@...il.com>
Cc:     Linux-MM <linux-mm@...ck.org>, linux-kernel@...r.kernel.org,
        Dan Streetman <ddstreet@...e.org>, Oleksiy.Avramchenko@...y.com
Subject: Re: [PATCH] z3fold: use per-cpu unbuddied lists

On Wed, 2 Aug 2017 12:25:05 +0200 Vitaly Wool <vitalywool@...il.com> wrote:

> z3fold is operating on unbuddied lists in a simple manner: in fact,
> it only takes the first entry off the list on a hot path. So if the
> z3fold pool is big enough and balanced well enough, considering
> only the lists local to the current CPU won't be an issue in any
> way, while random I/O performance will go up.

Has the performance benefit been measured?  It's a large patch.

> This patch also introduces two worker threads which: one for async
> in-page object layout optimization and one for releasing freed
> pages.

Why?  What are the runtime effects of this change?  Does this turn
currently-synchronous operations into now-async operations?  If so,
what are the implications of this if, say, the workqueue doesn't get
serviced for a while?

etc.  Sorry, but I'm not seeing anywhere near enough information and
testing results to justify merging such a large and intrusive patch.