[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1344015550.9299.1387.camel@edumazet-glaptop>
Date: Fri, 03 Aug 2012 19:39:10 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Sasha Levin <levinsasha928@...il.com>
Cc: torvalds@...ux-foundation.org, tj@...nel.org,
akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, paul.gortmaker@...driver.com,
davem@...emloft.net, rostedt@...dmis.org, mingo@...e.hu,
ebiederm@...ssion.com, aarcange@...hat.com, ericvh@...il.com,
netdev@...r.kernel.org
Subject: Re: [RFC v2 1/7] hashtable: introduce a small and naive hashtable
On Fri, 2012-08-03 at 16:23 +0200, Sasha Levin wrote:
> This hashtable implementation is using hlist buckets to provide a simple
> hashtable to prevent it from getting reimplemented all over the kernel.
>
> +static void hash_add(struct hash_table *ht, struct hlist_node *node, long key)
> +{
> + hlist_add_head(node,
> + &ht->buckets[hash_long((unsigned long)key, HASH_BITS(ht))]);
> +}
> +
Why key is a long, casted later to "unsigned long" ?
hash_long() is expensive on 64bit arches, and not really needed
if key is an u32 from the beginning ( I am referring to your patches 6 &
7 using jhash() )
Maybe you could use a macro, so that we can automatically select
hash_32() if key is an u32, and hash_long() for other types.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists