From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: NeilBrown <neilb@suse.com>
Cc: Oleg Drokin <oleg.drokin@intel.com>,
James Simmons <jsimmons@infradead.org>,
Andreas Dilger <andreas.dilger@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>
Subject: [lustre-devel] [PATCH 00/20] staging: lustre: convert to rhashtable
Date: Mon, 23 Apr 2018 15:08:37 +0200 [thread overview]
Message-ID: <20180423130837.GA25183@kroah.com> (raw)
In-Reply-To: <152348312863.12394.11915752362061083241.stgit@noble>
On Thu, Apr 12, 2018 at 07:54:48AM +1000, NeilBrown wrote:
> libcfs in lustre has a resizeable hashtable.
> Linux already has a resizeable hashtable, rhashtable, which is better
> is most metrics. See https://lwn.net/Articles/751374/ in a few days
> for an introduction to rhashtable.
>
> This series converts lustre to use rhashtable. This affects several
> different tables, and each is different is various ways.
>
> There are two outstanding issues. One is that a bug in rhashtable
> means that we cannot enable auto-shrinking in one of the tables. That
> is documented as appropriate and should be fixed soon.
>
> The other is that rhashtable has an atomic_t which counts the elements
> in a hash table. At least one table in lustre went to some trouble to
> avoid any table-wide atomics, so that could lead to a regression.
> I'm hoping that rhashtable can be enhanced with the option of a
> per-cpu counter, or similar.
>
>
> I have enabled automatic shrinking on all tables where it makes sense
> and doesn't trigger the bug. I have also removed all hints concerning
> min/max size - I cannot see how these could be useful.
>
> The dump_pgcache debugfs file provided some interesting challenges. I
> think I have cleaned it up enough so that it all makes sense. An
> extra pair of eyes examining that code in particular would be
> appreciated.
>
> This series passes all the same tests that pass before the patches are
> applied.
I've taken the first 4 patches of this series, as they were "obviously
correct". I'll let you and James argue about the rest. Feel free to
resend when there's some sort of agreement.
thanks,
greg k-h
prev parent reply other threads:[~2018-04-23 13:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-11 21:54 [lustre-devel] [PATCH 00/20] staging: lustre: convert to rhashtable NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 11/20] staging: lustre: lu_object: discard extra lru count NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 08/20] staging: lustre: simplify ldlm_ns_hash_defs[] NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 05/20] staging: lustre: separate buckets from ldlm hash table NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 07/20] staging: lustre: ldlm: store name directly in namespace NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 04/20] staging: lustre: convert osc_quota hash to rhashtable NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 03/20] staging: lustre: convert obd uuid " NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 02/20] staging: lustre: convert lov_pool to use rhashtable NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 12/20] staging: lustre: lu_object: factor out extra per-bucket data NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 06/20] staging: lustre: ldlm: add a counter to the per-namespace data NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 10/20] staging: lustre: make struct lu_site_bkt_data private NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 09/20] staging: lustre: convert ldlm_resource hash to rhashtable NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 01/20] staging: lustre: ptlrpc: convert conn_hash " NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 13/20] staging: lustre: lu_object: move retry logic inside htable_lookup NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 14/20] staging: lustre: fold lu_object_new() into lu_object_find_at() NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 16/20] staging: lustre: llite: remove redundant lookup in dump_pgcache NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 17/20] staging: lustre: use call_rcu() to free lu_object_headers NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 15/20] staging: lustre: llite: use more private data in dump_pgcache NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 18/20] staging: lustre: change how "dump_page_cache" walks a hash table NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 20/20] staging: lustre: remove cfs_hash resizeable hashtable implementation NeilBrown
2018-04-11 21:54 ` [lustre-devel] [PATCH 19/20] staging: lustre: convert lu_object cache to rhashtable NeilBrown
2018-04-17 3:35 ` [lustre-devel] [PATCH 00/20] staging: lustre: convert " James Simmons
2018-04-18 3:17 ` NeilBrown
2018-04-18 21:56 ` Simmons, James A.
2018-04-23 13:08 ` Greg Kroah-Hartman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180423130837.GA25183@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=andreas.dilger@intel.com \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=neilb@suse.com \
--cc=oleg.drokin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.