[<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