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]
Message-Id: <20170802160716.f5d1072873799a3a420f6538@linux-foundation.org>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ