经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 程序设计 » Python3 » 查看文章
记一次 splice 导致 io.Copy 阻塞的排查过程
来源：cnblogs　　作者：小胖西瓜　　时间：2024/2/26 15:06:53　　对本文有异议

记一次 splice 导致 io.Copy 阻塞的排查过程

简而言之，net.TCPConn 的 ReadFrom 零拷贝实现 splice 在 1.21.0 - 1.21.4 删除了 SPLICE_F_NONBLOCK 参数，导致在 CentOS7.2(内核版本 3.10.0) 上 splice 被阻塞。

相关的 issue 为 https://github.com/golang/go/issues/59041

这个问题在 1.21.5 中被修复，commit 为 https://github.com/yunginnanet/go/commit/35afad885d5e046a4a14643b5b530b128ca953de

背景

由于环境的问题，需要有一个 TCP 的代理，之前一直用 ncat -vl 10022 -k -c 'ncat -nv 127.0.0.1 22' 方式将 10022 端口的流量代理至 127.0.0.1:22，但是 ncat 是一个连接一个进程，如果要做短连接压测的，代理会成为瓶颈。

所以决定换个代理的软件，因为 Go 写一个代理特别简单，十行代码就能实现一个性能不错的服务，那就直接自己写一个。

  1. package main
  3. import (
  4. 	"flag"
  5. 	"fmt"
  6. 	"io"
  7. 	"net"
  8. 	"sync"
  10. 	"github.com/sirupsen/logrus"
  11. )
  13. func main() {
  14. 	f := flag.String("from", "", "source addr")
  15. 	t := flag.String("to", "", "dest addr")
  16. 	flag.Parse()
  18. 	if *f == "" || *t == "" {
  19. 		fmt.Println("Invalid from/to address")
  20. 		return
  21. 	}
  22. 	logrus.WithFields(logrus.Fields{"from": *f, "to": *t}).Info("Setup proxy server")
  24. 	lis, err := net.Listen("tcp", *f)
  25. 	if err != nil {
  26. 		panic(err)
  27. 	}
  28. 	logrus.WithField("addr", lis.Addr()).Info("Listen on")
  30. 	for {
  31. 		conn, err := lis.Accept()
  32. 		if err != nil {
  33. 			panic(err)
  34. 		}
  35. 		go handleConn(conn, *t)
  36. 	}
  37. }
  39. func handleConn(uConn net.Conn, to string) {
  40. 	logrus.WithField("addr", uConn.RemoteAddr()).Info("New conn")
  41. 	defer uConn.Close()
  43. 	rConn, err := net.Dial("tcp", to)
  44. 	if err != nil {
  45. 		logrus.WithError(err).Error("Fail to net.DialTCP")
  46. 		return
  47. 	}
  48. 	logrus.WithField("local", rConn.LocalAddr()).Info("Start proxy conn")
  50. 	wg := sync.WaitGroup{}
  51. 	wg.Add(2)
  52. 	go func() {
  53. 		defer wg.Done()
  54. 		io.Copy(uConn, rConn)
  55. 		rConn.Close()
  56. 		uConn.Close()
  57. 	}()
  58. 	go func() {
  59. 		defer wg.Done()
  60. 		io.Copy(rConn, uConn)
  61. 		uConn.Close()
  62. 		rConn.Close()
  63. 	}()
  64. 	wg.Wait()
  65. }

编译操作系统为 Debian12，Go 版本为 1.21.1。

因为默认路由的原因，我把这个服务部署在了一个 CentOS7.2 的虚拟机里面，压测发现QPS总是上不去。

用 tcpdump 抓包定位到是这边的代理程序有问题，流量没有被正确的进行转发。

为避免出现敏感数据，用下面的图来做模拟，在 A 使用 scp 向 B 发送文件，中间经过了个我们写的服务 PROXY

  1. +----------------+      +-------------------------------+
  2. |  (A) Debian12  |      |  (B) CentOS7.2                |
  3. |                | <--> | 192.168.32.251:10022          |
  4. | 192.168.32.251 |      |        └─> PROXY              |
  5. |                |      |              └─> 127.0.0.1:22 |
  6. +----------------+      +-------------------------------+
  8. # 生成一个大的文件
  9. #   dd if=/dev/zero of=/tmp/1.txt bs=1M count=1024
  10. # 使用命令模拟压测
  11. #   scp -P 10022 /tmp/1.txt root@192.168.32.245:/tmp/

排查

ps 看到这个进程还在运行，所以不是进程退出导致的。

top 观察进程 CPU 占用也不高，所以不是代码写出死循环来了。

由于程序没有加日志，通过 strace -p $(pidof PROXY) 来分析一下当前哪些系统调用在执行，看起来是 epoll_pwait 没有就绪事件返回。

  1. [pid 26877] splice(14, NULL, 18, NULL, 1048576, 0) = -1 EAGAIN (Resource temporarily unavailable)
  2. [pid 26790] epoll_pwait(5,  <unfinished ...>
  3. [pid 26788] nanosleep({tv_sec=0, tv_nsec=20000},  <unfinished ...>
  4. [pid 26790] <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
  5. [pid 26877] epoll_pwait(5,  <unfinished ...>
  6. [pid 26790] epoll_pwait(5,  <unfinished ...>
  7. [pid 26877] <... epoll_pwait resumed>[], 128, 0, NULL, 0) = 0
  8. [pid 26877] futex(0xc000040d48, FUTEX_WAIT_PRIVATE, 0, NULL <unfinished ...>
  9. [pid 26788] <... nanosleep resumed>NULL) = 0
  10. [pid 26788] futex(0x5ea8a0, FUTEX_WAIT_PRIVATE, 0, {tv_sec=60, tv_nsec=0} <unfinished ...>
  11. [pid 26790] <... epoll_pwait resumed>[{EPOLLIN|EPOLLOUT, {u32=2345140225, u64=9221451948300435457}}], 128, -1, NULL, 0) = 1
  12. [pid 26790] epoll_pwait(5, [], 128, 0, NULL, 0) = 0
  13. [pid 26790] epoll_pwait(5, [{EPOLLIN|EPOLLOUT, {u32=2345140225, u64=9221451948300435457}}], 128, -1, NULL, 0) = 1
  14.          多条 epoll_pwait 省略

看看连接缓冲区里面有没有数据 netstat -ntp | grep 10022，在接受缓冲区内还有 1666120 个字节的数据没有被读出

  1. tcp6  1666120      0 192.168.32.245:10022    192.168.32.251:49440    ESTABLISHED 26787/PROXY

当时想着看看重启能不能复现，在重启之前先 kill -3 把堆栈打印出来，拿到了一个关键的栈信息。

  1. goroutine 19 [syscall]:
  2. syscall.Syscall6(0x7ff92db08be8?, 0xc000068c88?, 0x45fca5?, 0xc000068c98?, 0x48ed3c?, 0xc000068cb0?, 0x48eea7?)
  3.         /usr/local/go1.21/src/syscall/syscall_linux.go:91 +0x30 fp=0xc000068c60 sp=0xc000068bd8 pc=0x481b50
  4. syscall.Splice(0xc000102000?, 0xc000068d08?, 0x0?, 0x4e70c0?, 0x4e70c0?, 0xc000068d20?)
  5.         /usr/local/go1.21/src/syscall/zsyscall_linux_amd64.go:1356 +0x45 fp=0xc000068cc0 sp=0xc000068c60 pc=0x480d05
  6. internal/poll.splice(...)
  7.         /usr/local/go1.21/src/internal/poll/splice_linux.go:155
  8. internal/poll.spliceDrain(0xc000102100?, 0xc000102000, 0x5a800?)
  9.         /usr/local/go1.21/src/internal/poll/splice_linux.go:92 +0x185 fp=0xc000068d68 sp=0xc000068cc0 pc=0x4917c5
  10. internal/poll.Splice(0x0?, 0x0?, 0x7fffffffffffffff)
  11.         /usr/local/go1.21/src/internal/poll/splice_linux.go:42 +0x173 fp=0xc000068e00 sp=0xc000068d68 pc=0x491413
  12. net.splice(0x0?, {0x53bca8?, 0xc000106000?})
  13.         /usr/local/go1.21/src/net/splice_linux.go:39 +0xdf fp=0xc000068e60 sp=0xc000068e00 pc=0x4cc29f
  14. net.(*TCPConn).readFrom(0xc000106008, {0x53bca8, 0xc000106000})
  15.         /usr/local/go1.21/src/net/tcpsock_posix.go:48 +0x28 fp=0xc000068e90 sp=0xc000068e60 pc=0x4cd0c8
  16. net.(*TCPConn).ReadFrom(0xc000106008, {0x53bca8?, 0xc000106000?})
  17.         /usr/local/go1.21/src/net/tcpsock.go:130 +0x30 fp=0xc000068ed0 sp=0xc000068e90 pc=0x4cc770
  18. io.copyBuffer({0x53bd68, 0xc000106008}, {0x53bca8, 0xc000106000}, {0x0, 0x0, 0x0})
  19.         /usr/local/go1.21/src/io/io.go:416 +0x147 fp=0xc000068f50 sp=0xc000068ed0 pc=0x47d587
  20. io.Copy(...)
  21.         /usr/local/go1.21/src/io/io.go:389
  22. main.handleConn.func2()
  23.         /home/devel/demo/app/demo/main.go:73 +0xb2 fp=0xc000068fe0 sp=0xc000068f50 pc=0x4db672
  24. runtime.goexit()
  25.         /usr/local/go1.21/src/runtime/asm_amd64.s:1650 +0x1 fp=0xc000068fe8 sp=0xc000068fe0 pc=0x464641
  26. created by main.handleConn in goroutine 17
  27.         /home/devel/demo/app/demo/main.go:71 +0x368

分析看到在 io.Copy 这条路线有问题，先看看 io.Copy 的源码

分析 io.Copy

io.Copy 内部有这么一段代码，优先于 read/write 调用，上面的堆栈打印看起来也是这个 ReadFrom 里面有问题。

  1. if wt, ok := src.(WriterTo); ok {
  2. 	return wt.WriteTo(dst)
  3. }
  4. // Similarly, if the writer has a ReadFrom method, use it to do the copy.
  5. if rt, ok := dst.(ReaderFrom); ok {
  6. 	return rt.ReadFrom(src)
  7. }

OK 先跳过这个 ReadFrom 看看能不能行呢，于是把 io.Copy 里面的 WriteTo/ReadFrom 注释，并且直接放到外面来，使用一般的 read/write 调用。

编译运行，可行！！！

那么问题就只能在这个 ReadFrom 里面了，照着上面的堆栈，一路追到了 poll.Splice 内，但是之前没有用过 splice 这个函数，只知道是一个零拷贝相关的函数。好吧，Go 在这里还做了一些优化。

那看来还是得研究一下，这个 splice 系统调用。

分析 poll.Splice

在这之前先搜索了一些文档看了一下，这个 splice 的文档写的相当好，很快就能够理解。

文章里面的的这张图清晰的描述了两次 splice 就能通过 pipe 在内核就将数据发送出去，没有把数据从内核空间拷贝至用户空间。

为了减少语言的干扰，使用 C 照着 poll.Splice 重写了一遍，代码如下。在 splice_readfrom 内部，每次循环调用两次 splice，一次将源 sockfd 的数据放至 pipe 中，一次将 pipe 中的数据写入目的 sockfd 中。

  1. #define _GNU_SOURCE 1
  2. #include <arpa/inet.h>
  3. #include <assert.h>
  4. #include <errno.h>
  5. #include <fcntl.h>
  6. #include <inttypes.h>
  7. #include <netinet/in.h>
  8. #include <poll.h>
  9. #include <pthread.h>
  10. #include <stdio.h>
  11. #include <string.h>
  12. #include <unistd.h>
  14. #include <thread>
  16. static ssize_t splice_drain(int fd, int pipefd, size_t max) {
  17.   while (1) {
  18.     ssize_t n = splice(fd, NULL, pipefd, NULL, max, 0);
  19.     if (n >= 0)
  20.       return n;
  22.     // error handle
  23.     if (errno == EINTR)
  24.       continue;
  25.     else if (errno != EAGAIN)
  26.       return -1;
  27.   }
  28. }
  30. static ssize_t splice_pump(int pipefd, int fd, size_t in_pipe) {
  31.   ssize_t written = 0;
  32.   while (in_pipe > 0) {
  33.     ssize_t n = splice(pipefd, NULL, fd, NULL, in_pipe, 0);
  34.     if (n >= 0) {
  35.       in_pipe -= n;
  36.       written += n;
  37.       continue;
  38.     }
  40.     if (errno != EAGAIN)
  41.       return -1;
  42.   }
  43.   return written;
  44. }
  46. static const size_t kMaxSpliceSize = 1 << 20;
  48. ssize_t splice_readfrom(int dstfd, int srcfd) {
  49.   int pipefd[2];
  50.   if (pipe2(pipefd, 0) < 0)
  51.     return -1;
  53.   ssize_t written = 0;
  54.   ssize_t remain = INT64_MAX;
  55.   while (remain > 0) {
  56.     size_t max = kMaxSpliceSize;
  57.     if (max > (size_t)remain)
  58.       max = remain;
  60.     ssize_t in_pipe = splice_drain(srcfd, pipefd[1], max);
  61.     if (in_pipe < 0)
  62.       return -1;
  63.     else if (in_pipe == 0)
  64.       break;
  66.     ssize_t n = splice_pump(pipefd[0], dstfd, in_pipe);
  67.     if (n > 0) {
  68.       remain -= n;
  69.       written += n;
  70.     }
  71.   }
  72.   close(pipefd[0]);
  73.   close(pipefd[1]);
  74.   return written;
  75. }
  77. int main(int argc, char **argv) {
  78.   int sockfd = socket(AF_INET, SOCK_STREAM, 0);
  79.   if (sockfd < 0) {
  80.     perror("Fail to socket");
  81.     return -1;
  82.   }
  84.   int opt = 1;
  85.   setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, (const void *)&opt, sizeof(opt));
  87.   fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL, NULL) | O_NONBLOCK);
  89.   struct sockaddr_in addr;
  90.   addr.sin_family = AF_INET;
  91.   addr.sin_port = htons(10022);
  92.   addr.sin_addr.s_addr = htonl(INADDR_ANY);
  94.   if (bind(sockfd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
  95.     perror("Fail to bind");
  96.     return -1;
  97.   }
  99.   if (listen(sockfd, 10) < 0) {
  100.     perror("Fail to listen");
  101.     return -1;
  102.   }
  103.   printf("listen on\n");
  105.   int timeout = 3000;
  106.   struct pollfd fds = {sockfd};
  107.   fds.events |= POLLIN;
  109.   while (1) {
  110.     int ret = poll(&fds, 1, timeout);
  111.     if (ret > 0) {
  112.       struct sockaddr_in in;
  113.       socklen_t len = sizeof(in);
  114.       int connfd = accept(sockfd, (struct sockaddr *)&in, &len);
  115.       if (connfd < 0) {
  116.         perror("Fail to accept");
  117.         return -1;
  118.       }
  120.       fcntl(connfd, F_SETFL, fcntl(connfd, F_GETFL, NULL) | O_NONBLOCK);
  122.       std::thread t(
  123.           [](struct sockaddr_in addr, int u_connfd) {
  124.             int sockfd = socket(AF_INET, SOCK_STREAM, 0);
  125.             if (sockfd < 0) {
  126.               perror("Fail to socket");
  127.               return;
  128.             }
  130.             struct sockaddr_in dst_addr;
  131.             dst_addr.sin_family = AF_INET;
  132.             dst_addr.sin_port = htons(10022);
  133.             dst_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
  135.             if (connect(sockfd, (struct sockaddr *)&dst_addr,
  136.                         sizeof(dst_addr)) < 0) {
  137.               perror("Fail to connect");
  138.               return;
  139.             }
  141.             char dst_txt[INET_ADDRSTRLEN];
  142.             char src_txt[INET_ADDRSTRLEN];
  144.             inet_ntop(AF_INET, &addr.sin_addr, src_txt, sizeof(src_txt));
  145.             printf("New conn from %s:%d\n", src_txt, ntohs(addr.sin_port));
  147.             std::thread t1([&]() { splice_readfrom(sockfd, u_connfd); });
  148.             std::thread t2([&]() { splice_readfrom(u_connfd, sockfd); });
  149.             t1.join();
  150.             t2.join();
  152.             close(sockfd);
  153.             close(u_connfd);
  154.           },
  155.           in, connfd);
  156.       t.detach();
  157.     }
  158.   }
  160.   return 0;
  161. }

测试下来，和 Go 版本表现一样，也是被阻塞，不过现在问题就更清晰一些，splice 的使用有问题。

于是仔细看了一下文档，里面有一个参数 SPLICE_F_NONBLOCK，要不加上试一下看看，加上之后程序是正常运行的。

所以会是这个参数的问题？在 Go 的实现里面，splice 的 flags 参数是为 0 的，也就是意味着是没有设置为非阻塞状态的。

想到我们之前的代理程序都没有出现这个情况，难道是 Go 版本的原因？于是使用 Go1.18 对 PROXY 进行编译运行，正常运行！

看了两个版本的实现，果然 Go1.18 是含有这个 SPLICE_F_NONBLOCK 参数的，在之后的版本内被删除了；继续搜索，发现了有人提了个上面的 issue。

对代码追踪发现 受影响版本为 1.21.0 - 1.21.4

扩展分析

issue 里面 Go 的开发者说所有的 case 都正常能跑过，所以把这个参数删除了。既然开发者测试没有问题，但是实际使用又有问题，那就有可能是环境不一致导致的。

分析未在不同内核上splice表现不一致

在上面的排查过程中，我还把 PROXY(Go1.21.1) 放到 A 中运行，代理至 192.168.32.245:22 上，表现也是正常的。经过测试，io.Copy 在不同的系统上的影响如下：

Kernel\Go 1.18.0 1.21.1
3.10 正常 不正常
6.1 正常 正常

1.18 是没有 BUG 的版本，也就是增加了 SPLICE_F_NONBLOCK 参数。那为何 1.21.1 版本没有增加这个参数的可以在 6.1 的内核上运行呢。

没有很好的头绪，难道是 pipe 导致的问题吗，pipe 太小了？于是调整 pipe 大小

  1. fcntl(pipefd[0], F_SETPIPE_SZ, 1 << 20);
  2. fcntl(pipefd[1], F_SETPIPE_SZ, 1 << 20);

使用 Go1.21.1 版本进行编译，并且进行测试，结果如下：

Kernel\Go 1.21.1
3.10 正常
6.1 正常

pipe 太小，那测试数据小于默认大小 65536 的看看会不会有问题

  1. dd if=/dev/zero of=/tmp/1.txt bs=1 count=65536

测试结果如下：

测试数据大小 测试结果
65536 不正常
32768 不正常
25000 不正常
16384 正常

splice 还有一个参数 len，为从 fd_in 到 pipe_w 中的字节数，如果我减少这个大小，那么结果会如何。测试下来 和调整 pipe 大小带来的结果相同。

那 splice 在不同内核上表现的结果不同这个问题，可以缩小一些排查的范围了：和 pipe 相关

不同内核的 splice 实现

看代码之前确认要关注的点：在哪里存在阻塞的动作

splice 实现位于 fs/splice.c 中，下面的代码取自 kernel-6.1(3.10 的内核代码也相似，主体逻辑没有变化)

  1. SYSCALL_DEFINE6(splice, ...) // fs/splice.c
  2.   -> __do_splice
  3.     -> do_splice
  4.       -> splice_file_to_pipe  // 将 sockfd 的数据传输至 pipe 中，走这条路径
  5.         -> do_splice_to
  6.           -> tcp_splice_read (in->f_op->splice_read) // net/ipv4/tcp.c
  7.             -> __tcp_splice_read
  8.               -> tcp_read_sock
  9.                 -> tcp_splice_data_recv
  10.                   -> skb_splice_bits                 // net/core/ipv4/skbuff.c
  11.                     -> splice_to_pipe                // fs/splice.c

经过 TCP 的读取，兜兜转转又回到 fs/splice.c 中。

kernel-6.1 的实现

在 kernel-6.1 的实现中，spclie_to_pipe 的实现没有阻塞

  1. ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
  2. 		       struct splice_pipe_desc *spd)
  3. {
  4.   // ....
  5. 	while (!pipe_full(head, tail, pipe->max_usage)) {
  6. 		struct pipe_buffer *buf = &pipe->bufs[head & mask];
  8. 		buf->page = spd->pages[page_nr];
  9. 		buf->offset = spd->partial[page_nr].offset;
  10. 		buf->len = spd->partial[page_nr].len;
  11. 		buf->private = spd->partial[page_nr].private;
  12. 		buf->ops = spd->ops;
  13. 		buf->flags = 0;
  15. 		head++;
  16. 		pipe->head = head;
  17. 		page_nr++;
  18. 		ret += buf->len;
  20. 		if (!--spd->nr_pages)
  21. 			break;
  22. 	}
  23. 	if (!ret)
  24. 		ret = -EAGAIN;
  26. out:
  27. 	while (page_nr < spd_pages)
  28. 		spd->spd_release(spd, page_nr++);
  30. 	return ret;
  31. }

向上回溯，在 splice_file_to_pipe 中，wait_for_space 中如果 pipe 满了则进行等待 pipe_wait_writable(pipe)

  1. long splice_file_to_pipe(struct file *in,
  2. 			 struct pipe_inode_info *opipe,
  3. 			 loff_t *offset,
  4. 			 size_t len, unsigned int flags)
  5. {
  6. 	long ret;
  8. 	pipe_lock(opipe);
  9. 	ret = wait_for_space(opipe, flags);
  10. 	if (!ret)
  11. 		ret = do_splice_to(in, offset, opipe, len, flags);
  12. 	pipe_unlock(opipe);
  13. 	if (ret > 0)
  14. 		wakeup_pipe_readers(opipe);
  15. 	return ret;
  16. }
  18. static int wait_for_space(struct pipe_inode_info *pipe, unsigned flags)
  19. {
  20. 	for (;;) {
  21. 		if (unlikely(!pipe->readers)) {
  22. 			send_sig(SIGPIPE, current, 0);
  23. 			return -EPIPE;
  24. 		}
  25. 		if (!pipe_full(pipe->head, pipe->tail, pipe->max_usage))
  26. 			return 0;
  27. 		if (flags & SPLICE_F_NONBLOCK)
  28. 			return -EAGAIN;
  29. 		if (signal_pending(current))
  30. 			return -ERESTARTSYS;
  31. 		pipe_wait_writable(pipe);
  32. 	}
  33. }

调整测试代码，对 pipe 只生产而不不消费数据。

  1. ssize_t splice_readfrom(int dstfd, int srcfd) {
  2.     ...
  3.     ssize_t in_pipe = splice_drain(srcfd, pipefd[1], max);
  5.     sleep(1);
  6.     written += in_pipe;
  7.     printf("+%ld written=%ld\n", in_pipe, written);
  8.     continue;
  10.     ssize_t n = splice_pump(pipefd[0], dstfd, in_pipe);
  11. }

为避免 ssh 的元数据干扰，不再使用 sshd 127.0.0.1:22 作为最后点，转而写了一个 io.Discard 的 Go 服务。
测试客户端为 ncat -nv 192.168.32.251 10022 < /tmp/1.txt

在 Debian12(kernel-6.1) 上进行测试，结果如下

  1. +65509 written=65509
  2. +57344 written=122853
  3. +49152 written=172005
  4. +36864 written=208869
  5. +28672 written=237541
  6. +20480 written=258021
  7. +16384 written=274405
  8. +8192 written=282597
  9. +4096 written=286693
  10. // 之后阻塞

pipe 的大小为 65536(PAGE_SIZE * 16)，但是写入的数据大于了 pipe 的缓冲区后，还能够继续写入，这点和可能和 skbuff/pipe 的 PAGE 有关，这里先跳过，直接测试一下在 CentOS7.2 上表现如何，结果直接阻塞，第一个 splice 都没有返回，好吧看看代码。

kernel-3.10 的实现

同样找到关键的 splice_to_pipe 函数

  1. ssize_t splice_to_pipe(struct pipe_inode_info *pipe, struct splice_pipe_desc *spd)
  2. {
  3.   // ...
  4. 	for (;;) {
  5. 		if (pipe->nrbufs < pipe->buffers) {
  6. 			int newbuf = (pipe->curbuf + pipe->nrbufs) & (pipe->buffers - 1);
  7. 			struct pipe_buffer *buf = pipe->bufs + newbuf;
  9. 			buf->page = spd->pages[page_nr];
  10. 			buf->offset = spd->partial[page_nr].offset;
  11. 			buf->len = spd->partial[page_nr].len;
  12. 			buf->private = spd->partial[page_nr].private;
  13. 			buf->ops = spd->ops;
  14. 			if (spd->flags & SPLICE_F_GIFT)
  15. 				buf->flags |= PIPE_BUF_FLAG_GIFT;
  17. 			pipe->nrbufs++;
  18. 			page_nr++;
  19. 			ret += buf->len;
  21. 			if (!--spd->nr_pages)
  22. 				break;
  23. 			if (pipe->nrbufs < pipe->buffers)
  24. 				continue;
  26. 			break;
  27. 		}
  29. 		if (spd->flags & SPLICE_F_NONBLOCK) {
  30. 			if (!ret)
  31. 				ret = -EAGAIN;
  32. 			break;
  33. 		}
  35. 		pipe->waiting_writers++;
  36. 		pipe_wait(pipe);
  37. 		pipe->waiting_writers--;
  38. 	}
  39. 	return ret;
  40. }

代码删除了和信号相关的逻辑，整个循环内的关键路径

  • if (!--spd->nr_pages) 为数据页都被挂在 pipe 后退出循环
  • if (pipe->nrbufs < pipe->buffers) 为 pipe 中还有空间则继续运行
  • if (spd->flags & SPLICE_F_NONBLOCK) 为 pipe 没有空间但是设置了非阻塞，则直接返回
  • pipe_wait 为数据没有读完，但是 pipe 已经没有空间则直接被挂起

在上面分析未在不同内核上splice表现不一致的结果中，可以看到 16K 的数据是能够返回的，数据的大小大一些就被阻塞了。

对比分析

kernel-6.1 对 splice 的实现相较 kernel-3.10 做了关键的两点变化：

  1. 提前做了 pipe 的空判断，这样数据挂载函数 splice_to_pipe 内部就不用进行阻塞了，而 3.10 将空判断和数据的转移放在一起做了
    1. static int wait_for_space(struct pipe_inode_info *pipe, unsigned flags)
    2. {
    3. 	for (;;) {
    4. 		if (unlikely(!pipe->readers)) {
    5. 			send_sig(SIGPIPE, current, 0);
    6. 			return -EPIPE;
    7. 		}
    8. 		if (!pipe_full(pipe->head, pipe->tail, pipe->max_usage))
    9. 			return 0;
    10. 		if (flags & SPLICE_F_NONBLOCK)
    11. 			return -EAGAIN;
    12. 		if (signal_pending(current))
    13. 			return -ERESTARTSYS;
    14. 		pipe_wait_writable(pipe);
    15. 	}
    16. }
  2. 限制了单次 splice 读取的大小
    1. static long do_splice_to(struct file *in, loff_t *ppos,
    2. 			 struct pipe_inode_info *pipe, size_t len,
    3. 			 unsigned int flags)
    4. {
    5. 	/* Don't try to read more the pipe has space for. */
    6. 	p_space = pipe->max_usage - pipe_occupancy(pipe->head, pipe->tail);
    7. 	len = min_t(size_t, len, p_space << PAGE_SHIFT);
    9. 	return in->f_op->splice_read(in, ppos, pipe, len, flags);
    10. }

结合代码和测试程序进行分析一下
kernel-3.10 里面的实现可能在 splice_to_pipe 中就被阻塞了，pipe 可容纳的空间小于 skbuff 中的数据
kernel-6.1 由于每次都会判断是否为空，只向 pipe 中写入可容纳的数据，所以只要有空间就不会被阻塞。

那么就遗留另外一个问题，pipe 的可容纳大小在不同版本内核上的不一样，和文档里面的 65536 都有一些明显出入，但是测试 pipe 的 write，则是准确的 65536. 据查资料得到的结论，fd -> pipe -> fd 这个过程只是 skbuff 的 PAGE 变化，内核不会再进行额外的内存分配。

上面的分析还需要通过调试来进行证明，那可以再写一篇文章通过kprobe分析 splice 了，这里再挖一个坑。

结论

这个问题只在低版本的内核上有问题，在高版本 Debian12 是正常的，在 Go1.21.5 中已经修复，建议使用 Go1.21.5 及以上的版本。

TODO

通过 kprobe 来分析 splice 下的 pipe 空间变化

参考

原文链接：https://www.cnblogs.com/shuqin/p/18031269

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Python3热门文章

  • PyQt-Fluent-Widgets：一个 Fluent Design 风格的组件库
  • Python3读取文件的操作详解
  • 口播神器,基于Edge,微软TTS(text-to-speech)文字转语音免费开源库edge-tts实践(Python3.10)
  • 向量数据库Chroma极简教程
  • 笔精墨妙,妙手丹青,微软开源可视化版本的ChatGPT:Visual ChatGPT,人工智能AI聊天发图片,Python3.10实现
  • win10+vs2019 编译webrtc m108
  • 闻其声而知雅意,基于Pytorch(mps/cpu/cuda)的人工智能AI本地语音识别库Whisper(Python3.10)
  • 靶机练习: Vikings
  • Python3 实现将bytes图片转jpg格式
  • MacBook m1芯片采用miniforge安装python3.9的方法示例

    • Python3推荐文章

  • 分页查询及其拓展应用案例
  • adorner 使用示例
  • 使用pyqt5制作简单计分桌面应用
  • cuda性能优化-2.访存优化
  • 通过钩子函数+Traceid实现Flask链路追踪
  • RCTF 2024 WEB wp
  • 【昇腾开发全流程】AscendCL开发板模型推理
  • PVT：特征金字塔在Vision Transormer的首次应用，又快又好 | ICCV 2021
  • 「网络流浅谈」最小割的模型 - E-Syrus
  • 比Selenium更优秀的playwright介绍与未来展望

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号