linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: torvalds@linux-foundation.org, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	paul.gortmaker@windriver.com, davem@davemloft.net,
	rostedt@goodmis.org, mingo@elte.hu, ebiederm@xmission.com,
	aarcange@redhat.com, ericvh@gmail.com, netdev@vger.kernel.org,
	josh@joshtriplett.org, eric.dumazet@gmail.com,
	mathieu.desnoyers@efficios.com, axboe@kernel.dk, agk@redhat.com,
	dm-devel@redhat.com, neilb@suse.de, ccaulfie@redhat.com,
	teigland@redhat.com, Trond.Myklebust@netapp.com,
	bfields@fieldses.org, fweisbec@gmail.com, jesse@nicira.com,
	venkat.x.venkatsubra@oracle.com, ejt@redhat.com,
	snitzer@redhat.com, edumazet@google.com,
	linux-nfs@vger.kernel.org, dev@openvswitch.org,
	rds-devel@oss.oracle.com, lw@cn.fujitsu.com
Subject: Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
Date: Wed, 22 Aug 2012 11:01:38 -0700	[thread overview]
Message-ID: <20120822180138.GA19212@google.com> (raw)
In-Reply-To: <1345602432-27673-2-git-send-email-levinsasha928@gmail.com>

Hello, Sasha.

On Wed, Aug 22, 2012 at 04:26:56AM +0200, Sasha Levin wrote:
> +#define DEFINE_HASHTABLE(name, bits)					\
> +	struct hlist_head name[HASH_SIZE(bits)];

Shouldn't this be something like the following?

#define DEFINE_HASHTABLE(name, bits)					\
	struct hlist_head name[HASH_SIZE(bits)] =			\
		{ [0 ... HASH_SIZE(bits) - 1] = HLIST_HEAD_INIT };

Also, given that the declaration isn't non-trivial, you'll probably
want a matching DECLARE_HASHTABLE() macro too.

> +/* Use hash_32 when possible to allow for fast 32bit hashing in 64bit kernels. */
> +#define hash_min(val, bits) ((sizeof(val)==4) ? hash_32((val), (bits)) : hash_long((val), (bits)))

Why is the branching condition sizeof(val) == 4 instead of <= 4?
Also, no biggie but why isn't this macro in caps?

> +/**
> + * hash_add_size - add an object to a hashtable
> + * @hashtable: hashtable to add to
> + * @bits: bit count used for hashing
> + * @node: the &struct hlist_node of the object to be added
> + * @key: the key of the object to be added
> + */
> +#define hash_add_size(hashtable, bits, node, key)				\
> +	hlist_add_head(node, &hashtable[hash_min(key, bits)]);
> +
> +/**
> + * hash_add - add an object to a hashtable
> + * @hashtable: hashtable to add to
> + * @node: the &struct hlist_node of the object to be added
> + * @key: the key of the object to be added
> + */
> +#define hash_add(hashtable, node, key)						\
> +	hash_add_size(hashtable, HASH_BITS(hashtable), node, key)

It would be nice if the comments actually say something which can
differentiate the two.  Ditto for rcu variants.

> +/**
> + * hash_add_rcu_size - add an object to a rcu enabled hashtable
> + * @hashtable: hashtable to add to
> + * @bits: bit count used for hashing
> + * @node: the &struct hlist_node of the object to be added
> + * @key: the key of the object to be added
> + */
> +#define hash_add_rcu_size(hashtable, bits, node, key)				\
> +	hlist_add_head_rcu(node, &hashtable[hash_min(key, bits)]);
> +
> +/**
> + * hash_add_rcu - add an object to a rcu enabled hashtable
> + * @hashtable: hashtable to add to
> + * @node: the &struct hlist_node of the object to be added
> + * @key: the key of the object to be added
> + */
> +#define hash_add_rcu(hashtable, node, key)					\
> +	hash_add_rcu_size(hashtable, HASH_BITS(hashtable), node, key)

Or maybe we're better off with hash_head_size() and hash_head()?  I'll
expand on it later.  Please bear with me.

> +/**
> + * hash_hashed - check whether an object is in any hashtable
> + * @node: the &struct hlist_node of the object to be checked
> + */
> +#define hash_hashed(node) (!hlist_unhashed(node))

As the 'h' in hlist* stand for hash anyway and I think this type of
thin wrappers tend to obfuscate more than anything else.

> +/**
> + * hash_del - remove an object from a hashtable
> + * @node: &struct hlist_node of the object to remove
> + */
> +static inline void hash_del(struct hlist_node *node)
> +{
> +	hlist_del_init(node);
> +}
> +
> +/**
> + * hash_del_rcu - remove an object from a rcu enabled hashtable
> + * @node: &struct hlist_node of the object to remove
> + */
> +static inline void hash_del_rcu(struct hlist_node *node)
> +{
> +	hlist_del_init_rcu(node);
> +}

If we do that, we can remove all these thin wrappers.

> +#define hash_for_each_size(name, bits, bkt, node, obj, member)			\
> +	for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)				\
> +		hlist_for_each_entry(obj, node, &name[bkt], member)
..
> +#define hash_for_each(name, bkt, node, obj, member)				\
> +	hash_for_each_size(name, HASH_BITS(name), bkt, node, obj, member)
...
> +#define hash_for_each_rcu_size(name, bits, bkt, node, obj, member)		\
> +	for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)				\
> +		hlist_for_each_entry_rcu(obj, node, &name[bkt], member)
...
> +#define hash_for_each_rcu(name, bkt, node, obj, member)				\
> +	hash_for_each_rcu_size(name, HASH_BITS(name), bkt, node, obj, member)
...
> +#define hash_for_each_safe_size(name, bits, bkt, node, tmp, obj, member)	\
> +	for (bkt = 0; bkt < HASH_SIZE(bits); bkt++)                     	\
> +		hlist_for_each_entry_safe(obj, node, tmp, &name[bkt], member)
...
> +#define hash_for_each_safe(name, bkt, node, tmp, obj, member)			\
> +	hash_for_each_safe_size(name, HASH_BITS(name), bkt, node,		\
> +				tmp, obj, member)
...
> +#define hash_for_each_possible_size(name, obj, bits, node, member, key)		\
> +	hlist_for_each_entry(obj, node,	&name[hash_min(key, bits)], member)
...
> +#define hash_for_each_possible(name, obj, node, member, key)			\
> +	hash_for_each_possible_size(name, obj, HASH_BITS(name), node, member, key)
...
> +#define hash_for_each_possible_rcu_size(name, obj, bits, node, member, key)	\
> +	hlist_for_each_entry_rcu(obj, node, &name[hash_min(key, bits)], member)
...
> +#define hash_for_each_possible_rcu(name, obj, node, member, key)		\
> +	hash_for_each_possible_rcu_size(name, obj, HASH_BITS(name),		\
...
> +#define hash_for_each_possible_safe_size(name, obj, bits, node, tmp, member, key)\
> +	hlist_for_each_entry_safe(obj, node, tmp,				\
> +		&name[hash_min(key, bits)], member)
...
> +#define hash_for_each_possible_safe(name, obj, node, tmp, member, key)		\
> +	hash_for_each_possible_safe_size(name, obj, HASH_BITS(name),		\

And also all these.  We'd only need hash_for_each_head() and
hash_head().  hash_for_each_possible*() could be nice for convenience,
I suppose.

I think the almost trivial nature of hlist hashtables makes this a bit
tricky and I'm not very sure but having this combinatory explosion is
a bit dazzling when the same functionality can be achieved by simply
combining operations which are already defined and named considering
hashtable.  I'm not feeling too strong about this tho.  What do others
think?

Also, can you please audit the comments on top of each macro?  They
have wrong names and don't differentiate the different variants very
well.

Thanks.

-- 
tejun

  reply	other threads:[~2012-08-22 18:01 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22  2:26 [PATCH v3 00/17] generic hashtable implementation Sasha Levin
2012-08-22  2:26 ` [PATCH v3 01/17] hashtable: introduce a small and naive hashtable Sasha Levin
2012-08-22 18:01   ` Tejun Heo [this message]
2012-08-22 23:54     ` Ryan Mallon
2012-08-23  0:24     ` Sasha Levin
2012-08-23 20:04       ` Tejun Heo
2012-08-24 19:47         ` Sasha Levin
2012-08-24 19:59           ` Tejun Heo
2012-08-24 20:11             ` Sasha Levin
2012-08-24 20:33               ` Tejun Heo
2012-08-24 20:53                 ` Sasha Levin
2012-08-24 21:23                   ` Tejun Heo
2012-08-24 22:59                     ` Sasha Levin
2012-08-24 23:07                       ` Tejun Heo
2012-08-25  4:24                         ` Mathieu Desnoyers
2012-08-28  9:56                           ` Sasha Levin
2012-08-28 10:11                             ` Mathieu Desnoyers
2012-08-28 11:27                               ` Sasha Levin
2012-08-28 11:56                                 ` Mathieu Desnoyers
2012-08-28 23:00                                   ` Mathieu Desnoyers
2012-09-04 15:35                                     ` Steven Rostedt
2012-09-04 16:30                                       ` Pedro Alves
2012-09-04 16:40                                         ` Pedro Alves
2012-09-04 17:01                                           ` Mathieu Desnoyers
2012-09-06 13:53                                             ` Sasha Levin
2012-09-06 14:19                                               ` Pedro Alves
2012-09-06 14:33                                               ` Mathieu Desnoyers
2012-09-06 14:36                                               ` David Laight
2012-09-06 14:55                                               ` Josh Triplett
2012-09-06 15:11                                                 ` Steven Rostedt
2012-09-06 15:49                                                 ` Sasha Levin
2012-09-06 16:00                                                   ` Steven Rostedt
2012-09-06 16:21                                                     ` Sasha Levin
2012-09-06 16:50                                                       ` Mathieu Desnoyers
2012-09-06 17:01                                                         ` Sasha Levin
2012-09-06 17:02                                                           ` Mathieu Desnoyers
2012-09-06 17:15                                                       ` Steven Rostedt
2012-09-04 17:17                                           ` Steven Rostedt
2012-09-04 17:21                                             ` Pedro Alves
2012-09-04 20:59                                               ` Steven Rostedt
2012-09-04 21:51                                                 ` Pedro Alves
2012-09-04 22:41                                                   ` Steven Rostedt
2012-09-04 22:58                                                     ` Pedro Alves
2012-09-04 23:27                                                       ` Steven Rostedt
2012-09-04 16:32                                       ` Mathieu Desnoyers
2012-08-22  2:26 ` [PATCH v3 02/17] userns: use new hashtable implementation Sasha Levin
2012-08-22  2:26 ` [PATCH v3 03/17] mm,ksm: " Sasha Levin
2012-08-22  2:26 ` [PATCH v3 04/17] workqueue: " Sasha Levin
2012-08-22 18:05   ` Tejun Heo
2012-08-22  2:27 ` [PATCH v3 05/17] mm/huge_memory: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 06/17] tracepoint: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 07/17] net,9p: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 08/17] block,elevator: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 09/17] SUNRPC/cache: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 10/17] dlm: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 11/17] net,l2tp: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 12/17] dm: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 13/17] lockd: " Sasha Levin
2012-08-22 11:47   ` J. Bruce Fields
2012-08-22 12:13     ` Sasha Levin
2012-08-22 13:12       ` J. Bruce Fields
2012-08-22 13:22       ` Mathieu Desnoyers
2012-08-22 17:32         ` Sasha Levin
2012-08-22  2:27 ` [PATCH v3 14/17] net,rds: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 15/17] openvswitch: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 16/17] tracing output: " Sasha Levin
2012-08-22  2:27 ` [PATCH v3 17/17] SUNRPC: use new hashtable implementation in auth Sasha Levin

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=20120822180138.GA19212@google.com \
    --to=tj@kernel.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=aarcange@redhat.com \
    --cc=agk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bfields@fieldses.org \
    --cc=ccaulfie@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dev@openvswitch.org \
    --cc=dm-devel@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=edumazet@google.com \
    --cc=ejt@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=ericvh@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=jesse@nicira.com \
    --cc=josh@joshtriplett.org \
    --cc=levinsasha928@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=lw@cn.fujitsu.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=neilb@suse.de \
    --cc=netdev@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=rds-devel@oss.oracle.com \
    --cc=rostedt@goodmis.org \
    --cc=snitzer@redhat.com \
    --cc=teigland@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=venkat.x.venkatsubra@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).