Re: [patch] arca-vm-2.2.5

Eric W. Biederman
1999-04-06T17:34:08Z

>>>>> "CL" == Chuck Lever <cel@monkey.org> writes:

CL> On Tue, 6 Apr 1999, Andrea Arcangeli wrote:
>> Cool! ;)) But could you tell me _how_ do you design an hash function? Are
>> you doing math or do you use instinct?

CL> math. i'll post something about this soon.

>> >but also the page hash function uses the hash table size as a shift value
>> >when computing the index, so it may combine the interesting bits in a
>> >different (worse) way when you change the hash table size. i'm planning
>> >to instrument the page hash to see exactly what's going on.
>>
>> Agreed. This is true. I thought about that and I am resizing the hash
>> table size to the original 11 bit now (since you are confirming that I
>> broken the hash function).

CL> i looked at doug's patch too, and it changes the "page_shift" value
CL> depending on the size of the hash table. again, this *may* cause unwanted
CL> interactions making the hash function degenerate for certain table sizes.
CL> but i'd like to instrument the hash to watch what really happens.

CL> i ran some simple benchmarks on our 4-way Xeon PowerEdge to see what are
CL> the effects of your patches. here were the original patches against
CL> 2.2.5.

CL> the page struct alignment patch:

>> --- linux/include/linux/mm.h Tue Mar 9 01:55:28 1999
>> +++ mm.h Tue Apr 6 02:00:22 1999
>> @@ -131,0 +133,6 @@
>> +#ifdef __SMP__
>> + /* cacheline alignment */
>> + char dummy[(sizeof(void *) * 7 +
>> + sizeof(unsigned long) * 2 +
>> + sizeof(atomic_t)) % L1_CACHE_BYTES];
>> +#endif

Am I the only one to notice that this little bit of code is totally wrong.
It happens to get it right for cache sizes of 16 & 32 with the current struct
page but the code is 100% backwords.

Eric