Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 01 5月, 2007 2 次提交
    • C
      SUNRPC: Eliminate side effects from rpc_malloc · c5a4dd8b
      由 Chuck Lever 提交于 
      Currently rpc_malloc sets req->rq_buffer internally.  Make this a more
generic interface:  return a pointer to the new buffer (or NULL) and
make the caller set req->rq_buffer and req->rq_bufsize.  This looks much
more like kmalloc and eliminates the side effects.

To fix a potential deadlock, this patch also replaces GFP_NOFS with
GFP_NOWAIT in rpc_malloc.  This prevents async RPCs from sleeping outside
the RPC's task scheduler while allocating their buffer.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c5a4dd8b
    • C
      SUNRPC: RPC buffer size estimates are too large · 2bea90d4
      由 Chuck Lever 提交于 
      The RPC buffer size estimation logic in net/sunrpc/clnt.c always
significantly overestimates the requirements for the buffer size.
A little instrumentation demonstrated that in fact rpc_malloc was never
allocating the buffer from the mempool, but almost always called kmalloc.

To compute the size of the RPC buffer more precisely, split p_bufsiz into
two fields; one for the argument size, and one for the result size.

Then, compute the sum of the exact call and reply header sizes, and split
the RPC buffer precisely between the two.  That should keep almost all RPC
buffers within the 2KiB buffer mempool limit.

And, we can finally be rid of RPC_SLACK_SPACE!
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      2bea90d4
  3. 06 12月, 2006 9 次提交
  5. 22 11月, 2006 1 次提交
    • D
      WorkStruct: Separate delayable and non-delayable events. · 52bad64d
      由 David Howells 提交于 
      Separate delayable work items from non-delayable work items be splitting them
into a separate structure (delayed_work), which incorporates a work_struct and
the timer_list removed from work_struct.

The work_struct struct is huge, and this limits it's usefulness.  On a 64-bit
architecture it's nearly 100 bytes in size.  This reduces that by half for the
non-delayable type of event.
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      52bad64d
  7. 04 10月, 2006 1 次提交
  9. 29 9月, 2006 1 次提交
  11. 23 9月, 2006 8 次提交
  13. 25 8月, 2006 1 次提交
  15. 04 8月, 2006 1 次提交
  17. 20 4月, 2006 1 次提交
  19. 21 3月, 2006 1 次提交
  21. 07 1月, 2006 3 次提交
    • 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: transport switch API for setting port number · 92200412
      由 Chuck Lever 提交于 
       At some point, transport endpoint addresses will no longer be IPv4.  To hide
 the structure of the rpc_xprt's address field from ULPs and port mappers,
 add an API for setting the port number during an RPC bind operation.

 Test-plan:
 Destructive testing (unplugging the network temporarily).  Connectathon
 with UDP and TCP.  NFSv2/3 and NFSv4 mounting should be carefully checked.
 Probably need to rig a server where certain services aren't running, or
 that returns an error for some typical operation.
Signed-off-by: NChuck Lever <cel@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      92200412
    • 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
  23. 19 10月, 2005 2 次提交
  25. 24 9月, 2005 9 次提交