Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 5月, 2007 1 次提交
    • 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. 21 4月, 2007 1 次提交
    • T
      RPC: Fix the TCP resend semantics for NFSv4 · 241c39b9
      由 Trond Myklebust 提交于 
      Fix a regression due to the patch "NFS: disconnect before retrying NFSv4
requests over TCP"

The assumption made in xprt_transmit() that the condition
	"req->rq_bytes_sent == 0 and request is on the receive list"
should imply that we're dealing with a retransmission is false.
Firstly, it may simply happen that the socket send queue was full
at the time the request was initially sent through xprt_transmit().
Secondly, doing this for each request that was retransmitted implies
that we disconnect and reconnect for _every_ request that happened to
be retransmitted irrespective of whether or not a disconnection has
already occurred.

Fix is to move this logic into the call_status request timeout handler.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      241c39b9
  5. 13 2月, 2007 1 次提交
  7. 11 2月, 2007 1 次提交
  9. 04 2月, 2007 1 次提交
  11. 06 12月, 2006 2 次提交
  13. 22 11月, 2006 1 次提交
    • D
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      由 David Howells 提交于 
      Pass the work_struct pointer to the work function rather than context data.
The work function can use container_of() to work out the data.

For the cases where the container of the work_struct may go away the moment the
pending bit is cleared, it is made possible to defer the release of the
structure by deferring the clearing of the pending bit.

To make this work, an extra flag is introduced into the management side of the
work_struct.  This governs auto-release of the structure upon execution.

Ordinarily, the work queue executor would release the work_struct for further
scheduling or deallocation by clearing the pending bit prior to jumping to the
work function.  This means that, unless the driver makes some guarantee itself
that the work_struct won't go away, the work function may not access anything
else in the work_struct or its container lest they be deallocated..  This is a
problem if the auxiliary data is taken away (as done by the last patch).

However, if the pending bit is *not* cleared before jumping to the work
function, then the work function *may* access the work_struct and its container
with no problems.  But then the work function must itself release the
work_struct by calling work_release().

In most cases, automatic release is fine, so this is the default.  Special
initiators exist for the non-auto-release case (ending in _NAR).
Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      65f27f38
  15. 29 9月, 2006 1 次提交
  17. 23 9月, 2006 7 次提交
  19. 04 8月, 2006 1 次提交
  21. 22 7月, 2006 1 次提交
  23. 09 6月, 2006 1 次提交
    • C
      SUNRPC: NFS_ROOT always uses the same XIDs · bf3fcf89
      由 Chuck Lever 提交于 
      The XID generator uses get_random_bytes to generate an initial XID.
NFS_ROOT starts up before the random driver, though, so get_random_bytes
doesn't set a random XID for NFS_ROOT.  This causes NFS_ROOT mount points
to reuse XIDs every time the client is booted.  If the client boots often
enough, the server will start serving old replies out of its DRC.

Use net_random() instead.

Test plan:
I/O intensive workloads should perform well and generate no errors.  Traces
taken during client reboots should show that NFS_ROOT mounts use unique
XIDs after every reboot.
Signed-off-by: NChuck Lever <cel@netapp.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      bf3fcf89
  25. 21 3月, 2006 5 次提交
  27. 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
  29. 19 10月, 2005 2 次提交
  31. 24 9月, 2005 11 次提交