[lkml]   [1999]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.021 / U:18.388 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site