>And at the same time nobody wants to hear about a patch which fixes
>one problem (hash lookup performance) while creating another (static
>increase in table size negatively effects low memory machines). See?
We are going dogslow and we could be fast while using 2.3.18ac8 for
testing. Is this smart? Such two liner change won't harm on the long run
as the auto-tuning hash feature is pending to be merged and it will kill
such #define line completly _careless_ about the value it had in the
ancient or recent past.
I am not proposing a cappy band aid that will make mess and it will be
hard to remove. I am _only_ tuning by hand the hash for the most machines
that are running 2.3.18ac8 _right_now_.
It's the _same_ like setting __SMP__ = 1 in the 2.1.x Makefile. An
embedded hardware developer would have set __SMP__ = 0 in the Makefile
before compiling the 2.1.100 binary image for his embedded hardware.
I sure _want_ the d/i cache hash autotuning merged and I appreciate your's
and Chuck's patches infact. But as right now the value is hardwired, it
should be set to a value that will make happy _most_ of testers until the
new autotuning feature will be merged. That's different than adding crap
to the kernel. See?
Andrea
-
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/