1. 11 Jan, 2011 1 commit
  2. 11 Sep, 2009 1 commit
  3. 17 Jun, 2009 1 commit
  4. 28 Apr, 2009 2 commits
  5. 04 Oct, 2008 1 commit
  6. 23 Apr, 2008 1 commit
  7. 01 Feb, 2008 14 commits
  8. 10 Jul, 2007 1 commit
  9. 09 May, 2007 1 commit
  10. 06 Mar, 2007 1 commit
  11. 12 Feb, 2007 3 commits
  12. 09 Feb, 2007 1 commit
    • NeilBrown's avatar
      [PATCH] knfsd: fix a race in closing NFSd connections · aaf68cfb
      NeilBrown authored
      If you lose this race, it can iput a socket inode twice and you get a BUG
      in fs/inode.c
      
      When I added the option for user-space to close a socket, I added some
      cruft to svc_delete_socket so that I could call that function when closing
      a socket per user-space request.
      
      This was the wrong thing to do.  I should have just set SK_CLOSE and let
      normal mechanisms do the work.
      
      Not only wrong, but buggy.  The locking is all wrong and it openned up a
      race where-by a socket could be closed twice.
      
      So this patch:
        Introduces svc_close_socket which sets SK_CLOSE then either leave
        the close up to a thread, or calls svc_delete_socket if it can
        get SK_BUSY.
      
        Adds a bias to sk_busy which is removed when SK_DEAD is set,
        This avoid races around shutting down the socket.
      
        Changes several 'spin_lock' to 'spin_lock_bh' where the _bh
        was missing.
      
      Bugzilla-url: http://bugzilla.kernel.org/show_bug.cgi?id=7916
      
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      aaf68cfb
  13. 04 Oct, 2006 1 commit
    • Greg Banks's avatar
      [PATCH] knfsd: knfsd: cache ipmap per TCP socket · 7b2b1fee
      Greg Banks authored
      Speed up high call-rate workloads by caching the struct ip_map for the peer on
      the connected struct svc_sock instead of looking it up in the ip_map cache
      hashtable on every call.  This helps workloads using AUTH_SYS authentication
      over TCP.
      
      Testing was on a 4 CPU 4 NIC Altix using 4 IRIX clients, each with 16
      synthetic client threads simulating an rsync (i.e.  recursive directory
      listing) workload reading from an i386 RH9 install image (161480 regular files
      in 10841 directories) on the server.  That tree is small enough to fill in the
      server's RAM so no disk traffic was involved.  This setup gives a sustained
      call rate in excess of 60000 calls/sec before being CPU-bound on the server.
      
      Profiling showed strcmp(), called from ip_map_match(), was taking 4.8% of each
      CPU, and ip_map_lookup() was taking 2.9%.  This patch drops both contribution
      into the profile noise.
      
      Note that the above result overstates this value of this patch for most
      workloads.  The synthetic clients are all using separate IP addresses, so
      there are 64 entries in the ip_map cache hash.  Because the kernel measured
      contained the bug fixed in commit
      
      commit 1f1e030b
      
      
      
      and was running on 64bit little-endian machine, probably all of those 64
      entries were on a single chain, thus increasing the cost of ip_map_lookup().
      
      With a modern kernel you would need more clients to see the same amount of
      performance improvement.  This patch has helped to scale knfsd to handle a
      deployment with 2000 NFS clients.
      Signed-off-by: default avatarGreg Banks <gnb@melbourne.sgi.com>
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7b2b1fee
  14. 02 Oct, 2006 8 commits
  15. 20 Mar, 2006 1 commit
  16. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4