Messages in this thread | | | Date | Thu, 23 Sep 1999 16:30:09 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: [patch] hashtable sizes for icache and dcache |
| |
On Thu, 23 Sep 1999, David S. Miller wrote:
>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/
| |