lkml.org 
[lkml]   [1999]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dynamic hash table allocation
On Thu, 17 Jun 1999, David S. Miller wrote:
> From: Chuck Lever <cel@monkey.org>
>
> i've included a simple shift-add replacement for the current buffer hash
> function. the buffer hash logic is now like the other hashes; there
> seemed to be no good reason for it to be different.
>
> Please factor in the device number in the buffer cache hash function,
> it matters a lot believe it or not.

taking the minor device number and adding it to the block number would be
simple enough, but mathematically adds very little randomness. i haven't
seen any benchmarks that are improved by keeping the device in the hash
function calculations. can you tell me why you think it should stay?

> Also, it appears as if a lot of the hash setup code does the same
> thing in all the spots, with only a few differences. It would be very
> nice if you could package this up into a generic "setup_hash_table()"
> function which were given minimal heuristics to size and allocate the
> hash table, and let the caller initialize it.

yes, there was a lot of cutting and pasting when i created this patch :)

i've been thinking about how to generalize this code a bit... there are a
lot of variables that would need to be passed into and out of such a
routine. we can simplify by putting all the hash table metadata into a
struct, and passing its address. if you think it is acceptible to use the
simple "num_physpages" based heuristic for most hash tables, that can be
included too.

- Chuck Lever
--
corporate: <chuckl@netscape.com>
personal: <chucklever@netscape.net> or <cel@monkey.org>

The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.059 / U:2.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site