1. 17 3月, 2008 6 次提交
  2. 13 3月, 2008 1 次提交
    • Z
      [NET]: Fix tbench regression in 2.6.25-rc1 · f1dd9c37
      Zhang Yanmin 提交于
      Comparing with kernel 2.6.24, tbench result has regression with
      2.6.25-rc1.
      
      1) On 2 quad-core processor stoakley: 4%.
      2) On 4 quad-core processor tigerton: more than 30%.
      
      bisect located below patch.
      
      b4ce9277 is first bad commit
      commit b4ce9277
      Author: Herbert Xu <herbert@gondor.apana.org.au>
      Date:   Tue Nov 13 21:33:32 2007 -0800
      
          [IPV6]: Move nfheader_len into rt6_info
      
          The dst member nfheader_len is only used by IPv6.  It's also currently
          creating a rather ugly alignment hole in struct dst.  Therefore this patch
          moves it from there into struct rt6_info.
      
      Above patch changes the cache line alignment, especially member
      __refcnt. I did a testing by adding 2 unsigned long pading before
      lastuse, so the 3 members, lastuse/__refcnt/__use, are moved to next
      cache line. The performance is recovered.
      
      I created a patch to rearrange the members in struct dst_entry.
      
      With Eric and Valdis Kletnieks's suggestion, I made finer arrangement.
      
      1) Move tclassid under ops in case CONFIG_NET_CLS_ROUTE=y. So
         sizeof(dst_entry)=200 no matter if CONFIG_NET_CLS_ROUTE=y/n. I
         tested many patches on my 16-core tigerton by moving tclassid to
         different place. It looks like tclassid could also have impact on
         performance.  If moving tclassid before metrics, or just don't move
         tclassid, the performance isn't good. So I move it behind metrics.
      
      2) Add comments before __refcnt.
      
      On 16-core tigerton:
      
      If CONFIG_NET_CLS_ROUTE=y, the result with below patch is about 18%
      better than the one without the patch;
      
      If CONFIG_NET_CLS_ROUTE=n, the result with below patch is about 30%
      better than the one without the patch.
      
      With 32bit 2.6.25-rc1 on 8-core stoakley, the new patch doesn't
      introduce regression.
      
      Thank Eric, Valdis, and David!
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Acked-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f1dd9c37
  3. 12 3月, 2008 7 次提交
  4. 11 3月, 2008 9 次提交
  5. 08 3月, 2008 2 次提交
    • K
    • P
      [NET]: Make /proc/net a symlink on /proc/self/net (v3) · e9720acd
      Pavel Emelyanov 提交于
      Current /proc/net is done with so called "shadows", but current
      implementation is broken and has little chances to get fixed.
      
      The problem is that dentries subtree of /proc/net directory has
      fancy revalidation rules to make processes living in different
      net namespaces see different entries in /proc/net subtree, but
      currently, tasks see in the /proc/net subdir the contents of any
      other namespace, depending on who opened the file first.
      
      The proposed fix is to turn /proc/net into a symlink, which points
      to /proc/self/net, which in turn shows what previously was in
      /proc/net - the network-related info, from the net namespace the
      appropriate task lives in.
      
      # ls -l /proc/net
      lrwxrwxrwx  1 root root 8 Mar  5 15:17 /proc/net -> self/net
      
      In other words - this behaves like /proc/mounts, but unlike
      "mounts", "net" is not a file, but a directory.
      
      Changes from v2:
      * Fixed discrepancy of /proc/net nlink count and selinux labeling
        screwup pointed out by Stephen.
      
        To get the correct nlink count the ->getattr callback for /proc/net
        is overridden to read one from the net->proc_net entry.
      
        To make selinux still work the net->proc_net entry is initialized
        properly, i.e. with the "net" name and the proc_net parent.
      
      Selinux fixes are
      Acked-by: NStephen Smalley <sds@tycho.nsa.gov>
      
      Changes from v1:
      * Fixed a task_struct leak in get_proc_task_net, pointed out by Paul.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9720acd
  6. 06 3月, 2008 15 次提交