1. 19 Mar, 2012 2 commits
    • Linus Torvalds's avatar
      Merge branch 'dcache-word-accesses' · b0e37d7a
      Linus Torvalds authored
      * branch 'dcache-word-accesses':
        vfs: use 'unsigned long' accesses for dcache name comparison and hashing
      
      This does the name hashing and lookup using word-sized accesses when
      that is efficient, namely on x86 (although any little-endian machine
      with good unaligned accesses would do).
      
      It does very much depend on little-endian logic, but it's a very hot
      couple of functions under some real loads, and this patch improves the
      performance of __d_lookup_rcu() and link_path_walk() by up to about 30%.
      Giving a 10% improvement on some very pathname-heavy benchmarks.
      
      Because we do make unaligned accesses past the filename, the
      optimization is disabled when CONFIG_DEBUG_PAGEALLOC is active, and we
      effectively depend on the fact that on x86 we don't really ever have the
      last page of usable RAM followed immediately by any IO memory (due to
      ACPI tables, BIOS buffer areas etc).
      
      Some of the bit operations we do are a bit "subtle".  It's commented,
      but you do need to really think about the code.  Or just consider it
      black magic.
      
      Thanks to people on G+ for some of the optimized bit tricks.
      b0e37d7a
    • Linus Torvalds's avatar
      vfs: get rid of batshit-insane pointless dentry hash calculations · 6d7d1a0d
      Linus Torvalds authored
      For some odd historical reason, the final mixing round for the dentry
      cache hash table lookup had an insane "xor with big constant" logic.  In
      two places.
      
      The big constant that is being xor'ed is GOLDEN_RATIO_PRIME, which is a
      fairly random-looking number that is designed to be *multiplied* with so
      that the bits get spread out over a whole long-word.
      
      But xor'ing with it is insane.  It doesn't really even change the hash -
      it really only shifts the hash around in the hash table.  To make
      matters worse, the insane big constant is different on 32-bit and 64-bit
      builds, even though the name hash bits we use are always 32-bit (and the
      bits from the pointer we mix in effectively are too).
      
      It's all total voodoo programming, in other words.
      
      Now, some testing and analysis of the hash chains shows that the rest of
      the hash function seems to be fairly good.  It does pick the right bits
      of the parent dentry pointer, for example, and while it's generally a
      bad idea to use an xor to mix down the upper bits (because if there is a
      repeating pattern, the xor can cause "destructive interference"), it
      seems to not have been a disaster.
      
      For example, replacing the hash with the normal "hash_long()" code (that
      uses the GOLDEN_RATIO_PRIME constant correctly, btw) actually just makes
      the hash worse.  The hand-picked hash knew which bits of the pointer had
      the highest entropy, and hash_long() ends up mixing bits less optimally
      at least in some trivial tests.
      
      So the hash function overall seems fine, it just has that really odd
      "shift result around by a constant xor".
      
      So get rid of the silly xor, and replace the down-mixing of the bits
      with an add instead of an xor that tends to not have the same kind of
      destructive interference issues.  Some stats on the resulting hash
      chains shows that they look statistically identical before and after,
      but the code is simpler and no longer makes you go "WTF?".
      
      Also, the incoming hash really is just "unsigned int", not a long, and
      there's no real point to worry about the high 26 bits of the dentry
      pointer for the 64-bit case, because they are all going to be identical
      anyway.
      
      So also change the hashing to be done in the more natural 'unsigned int'
      that is the real size of the actual hashed data anyway.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6d7d1a0d
  2. 18 Mar, 2012 3 commits
    • Linus Torvalds's avatar
      Linux 3.3 · c16fa4f2
      Linus Torvalds authored
      c16fa4f2
    • Jason Baron's avatar
      Don't limit non-nested epoll paths · 93dc6107
      Jason Baron authored
      Commit 28d82dc1 ("epoll: limit paths") that I did to limit the
      number of possible wakeup paths in epoll is causing a few applications
      to longer work (dovecot for one).
      
      The original patch is really about limiting the amount of epoll nesting
      (since epoll fds can be attached to other fds). Thus, we probably can
      allow an unlimited number of paths of depth 1. My current patch limits
      it at 1000. And enforce the limits on paths that have a greater depth.
      
      This is captured in: https://bugzilla.redhat.com/show_bug.cgi?id=681578Signed-off-by: default avatarJason Baron <jbaron@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      93dc6107
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · c579bc7e
      Linus Torvalds authored
      Pull networking changes from David Miller:
       "1) icmp6_dst_alloc() returns NULL instead of ERR_PTR() leading to
           crashes, particularly during shutdown.  Reported by Dave Jones and
           fixed by Eric Dumazet.
      
        2) hyperv and wimax/i2400m return NETDEV_TX_BUSY when they have
           already freed the SKB, which causes crashes as to the caller this
           means requeue the packet.  Fixes from Eric Dumazet.
      
        3) usbnet driver doesn't allocate the right amount of headroom on
           fresh RX SKBs, fix from Eric Dumazet.
      
        4) Fix regression in ip6_mc_find_dev_rcu(), as an RCU lookup it
           abolutely should not take a reference to 'dev', this leads to
           leaks.  Fix from RonQing Li.
      
        5) Fix netfilter ctnetlink race between delete and timeout expiration.
           From Pablo Neira Ayuso.
      
        6) Revert SFQ change which causes regressions, specifically queueing
           to tail can lead to unavoidable flow starvation.  From Eric
           Dumazet.
      
        7) Fix a memory leak and a crash on corrupt firmware files in bnx2x,
           from Michal Schmidt."
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        netfilter: ctnetlink: fix race between delete and timeout expiration
        ipv6: Don't dev_hold(dev) in ip6_mc_find_dev_rcu.
        wimax/i2400m: fix erroneous NETDEV_TX_BUSY use
        net/hyperv: fix erroneous NETDEV_TX_BUSY use
        net/usbnet: reserve headroom on rx skbs
        bnx2x: fix memory leak in bnx2x_init_firmware()
        bnx2x: fix a crash on corrupt firmware file
        sch_sfq: revert dont put new flow at the end of flows
        ipv6: fix icmp6_dst_alloc()
      c579bc7e
  3. 17 Mar, 2012 10 commits
  4. 16 Mar, 2012 24 commits
  5. 15 Mar, 2012 1 commit