[lkml]   [2005]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 9/11] net: dst_entry.refcount, use, lastuse to use alloc_percpu
    From: Ravikiran G Thirumalai <>
    Date: Tue, 13 Sep 2005 15:07:37 -0700

    > Agreed the dst changes are ugly; that can be worked on. But the
    > cacheline bouncing problem on the atomic_t dst_entry refcounter has
    > been around for quite a while -- even on SMPs, not just NUMA. We
    > need a solution for that. I thought you were against the dst_entry
    > bloat caused by the previous version of the dst patch. alloc_percpu
    > takes that away. You had concerns about workloads with low route
    > locality. Unfortunately we don't have access to infrastructure setup
    > for such tests :(

    You don't have two computers connected on a network?

    All you need is that, load a bunch of routes into one system that
    point to an IP address which you just force an ARP entry for (so it
    just gets lost in the ether) and then generate a rDOS workload through
    it from another machine using pktgen.

    I'm fine with funny per-cpu memory allocation strategies, perhaps
    (would have to see a patch doing _only_ that to be sure).

    But using bigrefs, no way. We have enough trouble making the data
    structures small without adding bloat like that. A busy server can
    have hundreds of thousands of dst cache entries active on it, and they
    chew up enough memory as is.
    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-09-14 00:14    [W:0.019 / U:38.972 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site