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/