1. 07 1月, 2006 3 次提交
    • T
      SUNRPC: Clean up xprt_destroy() · 0065db32
      Trond Myklebust 提交于
       We ought never to be calling xprt_destroy() if there are still active
       rpc_tasks. Optimise away the broken code that attempts to "fix" that case.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      0065db32
    • T
      SUNRPC: Ensure client closes the socket when server initiates a close · 632e3bdc
      Trond Myklebust 提交于
       If the server decides to close the RPC socket, we currently don't actually
       respond until either another RPC call is scheduled, or until xprt_autoclose()
       gets called by the socket expiry timer (which may be up to 5 minutes
       later).
      
       This patch ensures that xprt_autoclose() is called much sooner if the
       server closes the socket.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      632e3bdc
    • C
      SUNRPC: switchable buffer allocation · 02107148
      Chuck Lever 提交于
       Add RPC client transport switch support for replacing buffer management
       on a per-transport basis.
      
       In the current IPv4 socket transport implementation, RPC buffers are
       allocated as needed for each RPC message that is sent.  Some transport
       implementations may choose to use pre-allocated buffers for encoding,
       sending, receiving, and unmarshalling RPC messages, however.  For
       transports capable of direct data placement, the buffers can be carved
       out of a pre-registered area of memory rather than from a slab cache.
      
       Test-plan:
       Millions of fsx operations.  Performance characterization with "sio" and
       "iozone".  Use oprofile and other tools to look for significant regression
       in CPU utilization.
      Signed-off-by: NChuck Lever <cel@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      02107148
  2. 19 10月, 2005 2 次提交
  3. 24 9月, 2005 20 次提交
  4. 08 7月, 2005 1 次提交
  5. 25 6月, 2005 1 次提交
  6. 23 6月, 2005 5 次提交
  7. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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