> On Wed, 22 Sep 1999 kernel@kvack.org wrote:
>
> >considered an acceptable fix, even for the short term. Fix the problem,
> >not the symptoms.
>
> You are wrong. I fixed the _cause_. My fix was a compile time thing so to
> make it working everywhere you should add a kernel option to set the new
> value or the old value. We all want it autotuning of course so it was a
> missing feature but the fix was correct.
unless i'm missing something, this is what you have sent to linux-kernel:
-#define HASH_BITS 8
+#define HASH_BITS 14
#define HASH_SIZE (1UL << HASH_BITS)
-#define D_HASHBITS 10
+#define D_HASHBITS 14
#define D_HASHSIZE (1UL << D_HASHBITS)
this patch alone indeed is just fixing the symptoms. If such a patch makes
it into the kernel (by accident, your patch wasnt flagged 'incorrect', it
was flagged as 'look how much performance') then it indeed makes it harder
to get the _real_ patch of DaveM (and/or Chuck) to make it into the
kernel. So your patch actually made things harder. I can see nothing
compile-time about this - unless i've missed some other patch of yours. It
has been long known that playing with all the HASHBITS gets us better
performance on big-memory boxes, and i've been running such kernels for
some time. It has also been long known that this is a tough problem, and
we all were waiting for a patch like DaveM's to get proper boot-time hash
sizing.
about another, unrelated thing:
> 256 spurious_interrupt_bug 21.3333
are you using older stepping PPro boxes? If yes then please update your
BIOS and let me know if still occurs even with a new BIOS. In any case,
could you please try my latest APIC tree:
http://www.redhat.com/~mingo/smp-2.3.18-F8
this should apply to all later kernels. Thanks,
-- mingo
-
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/