Messages in this thread | | | Date | Thu, 17 Jun 1999 22:01:32 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: 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/
| |