[lkml]   [2004]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Limit the size of the IPV4 route hash.
    Robin Holt <> wrote:
    > I realize I have a special case which highlighted the problem. My case
    > shows that not putting an upper limit or at least a drastically aggressive
    > non-linear growth cap does cause issues. For the really large system,
    > we were seeing a size of 512MB for the hash which was limited because
    > that was the largest amount of memory available on a single node. I can
    > not ever imagine this being a reasonable limit. Not with 512 cpus and
    > 1024 network adapters could I envision that this level of hashing would
    > actually be advantageous given all the other lock contention that will
    > be seen.

    Half a gig for the hashtable does seems a bit nutty.

    > Can we agree that a linear calculation based on num_physpages is probably
    > not the best algorithm. If so, should we make it a linear to a limit or
    > a logarithmically decreasing size to a limit? How do we determine that
    > limit point?

    An initial default of N + M * log2(num_physpages) would probably give a
    saner result.

    The big risk is that someone has a too-small table for some specific
    application and their machine runs more slowly than it should, but they
    never notice. I wonder if it would be possible to put a little once-only
    printk into the routing code: "warning route-cache chain exceeded 100
    entries: consider using the rhash_entries boot option".

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

     \ /
      Last update: 2005-03-22 14:08    [W:0.020 / U:13.128 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site