mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2025-08-07 07:37:02 +02:00
OPTIM: splicing: use splice() for the last block when relevant
Splicing is avoided for small transfers because it's generally cheaper to perform a couple of recv+send calls than pipe+splice+splice. This has the consequence that the last chunk of a large transfer may be transferred using recv+send if it's less than 4 kB. But when the pipe is already set up, it's better to use splice() to read the pending data, since they will get merged with the pending ones. This is what now happens everytime the reader is slower than the writer. Note that this change alone could have fixed most of the CPU hog bug, except at the end when only the close was pending.
This commit is contained in:
parent
5007d2aa33
commit
fa8e2bc68c
@ -934,7 +934,8 @@ static void si_conn_recv_cb(struct connection *conn)
|
|||||||
* using a buffer.
|
* using a buffer.
|
||||||
*/
|
*/
|
||||||
if (conn->xprt->rcv_pipe &&
|
if (conn->xprt->rcv_pipe &&
|
||||||
chn->to_forward >= MIN_SPLICE_FORWARD && chn->flags & CF_KERN_SPLICING) {
|
(chn->pipe || chn->to_forward >= MIN_SPLICE_FORWARD) &&
|
||||||
|
chn->flags & CF_KERN_SPLICING) {
|
||||||
if (buffer_not_empty(chn->buf)) {
|
if (buffer_not_empty(chn->buf)) {
|
||||||
/* We're embarrassed, there are already data pending in
|
/* We're embarrassed, there are already data pending in
|
||||||
* the buffer and we don't want to have them at two
|
* the buffer and we don't want to have them at two
|
||||||
|
Loading…
Reference in New Issue
Block a user