All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Brian J. Watson" <Brian.J.Watson@compaq.com>
To: Andi Kleen <ak@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Common hash table implementation
Date: Fri, 20 Jul 2001 15:32:38 -0700	[thread overview]
Message-ID: <3B58B186.4D23D1A3@compaq.com> (raw)
In-Reply-To: <oupitgqjxoi.fsf@pigdrop.muc.suse.de>

Andi Kleen wrote:
> It's a "fuzzy hash", which is a bit different from the normal hash and
> probably not always appropiate.
> 
> It was at one point used in the dcache but then later ripped out again
> when the data structures changed.
> 

Ahh. I'm not familiar with fuzzy hashes, but I suspected they might
not be what I was interested in.


> I would like to see a generic hash abstraction in the spirit of list.h
> Especially if it would NOT use normal list_heads as open hash table
> heads but instead single pointers for the head [currently some important
> 
> hash tables like the inode hash are twice as big as needed because
> each bucket is two pointers instead of one]
> 

I agree. Hash tables such as inode_hashtable and dentry_hashtable are
half as efficient under stress as they would otherwise be, because
they use an array of list_heads.

OTOH, I have no objections to using list_heads in other applications
where a singly-linked list is all that's needed. Common code is a Good
Thing. I'm just commenting specifically on hash table implementations,
which tend to be used for really _big_ data structures.


-- 
Brian Watson                 | "The common people of England... so 
Linux Kernel Developer       |  jealous of their liberty, but like the 
Open SSI Clustering Project  |  common people of most other countries 
Compaq Computer Corp         |  never rightly considering wherein it 
Los Angeles, CA              |  consists..."
                             |      -Adam Smith, Wealth of Nations,
1776

mailto:Brian.J.Watson@compaq.com
http://opensource.compaq.com/

       reply	other threads:[~2001-07-20 22:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <oupitgqjxoi.fsf@pigdrop.muc.suse.de>
2001-07-20 22:32 ` Brian J. Watson [this message]
2001-07-21 22:57   ` Common hash table implementation Daniel Phillips
2001-07-18  0:57 Brian J. Watson
2001-07-18  1:34 ` Larry McVoy
2001-07-18 13:46   ` Daniel Phillips
2001-07-21  0:24     ` Brian J. Watson
2001-07-21 20:25       ` Daniel Phillips
2001-07-22 10:18         ` Richard Guenther
2001-07-23 14:36           ` Daniel Phillips
2001-07-22 16:37         ` Larry McVoy
2001-07-23 14:24           ` Daniel Phillips
2001-07-22 23:34         ` Eyal Lebedinsky
2001-07-24 12:57           ` Daniel Phillips
2001-07-22  2:23   ` Rusty Russell
2001-07-24 12:28     ` Daniel Phillips
2001-07-18  9:48 ` Richard Guenther

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=3B58B186.4D23D1A3@compaq.com \
    --to=brian.j.watson@compaq.com \
    --cc=ak@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.