libpmem有一个初始化操作在函数pmem_init里, 里边有初始化的一系列操作，东西太多，主要就是查架构，定下以后使用的函数等。我这里根据当前CPU架构，只看了需要用到的内容. 首先通过pmem2_arch_init(&info);初始化info。在libpmem2/x86_64/init.c里，pmem_cpuinfo_to_funcs(info, &impl);这个函数是判断flush支持的指令，从最低级开始判断，如果高级的支持，就直接替换。这个我看过cpuinfo是支持clwb，所以info->flush = flush_clwb; info->flush_has_builtin_fence = 0; info->fence = memory_barrier;。这里边很多环境变量的获取判断，都是调试或者制定模式的，这里先不管这些。SIMD支持avx512f，所以也直接看这个了，初步看着这个好像是为了MOVNT准备的就是ntstore，主要就定义一个memmove_nodrain。然后这里info就初始化完了。 flush_clwb,为flush_clwb_nolog(addr, len);在libpmem2/x86_64/flush.h里定义的： static force_inline void flush_clwb_nolog(const void *addr, size_t len) { uintptr_t uptr; /* * Loop through cache-line-size (typically 64B) aligned chunks * covering the given range. */ for (uptr = (uintptr_t)addr & ~(FLUSH_ALIGN - 1); uptr < (uintptr_t)addr + len; uptr += FLUSH_ALIGN) { pmem_clwb((char *)uptr); } } FLUSH_ALIGN为64，所以其实数据结构能对齐64B应该是好的，但是想了想应该没办法对齐。所以还是得计算对齐地址，但是小数据可以不需要for了，这个可以定制。pmem_clwb为CLWB void _mm_clwb(void const *p);这个gcc应该是支持的，等查一查，官方为了兼容，直接汇编实现的。memory_barrier为_mm_sfence();这个clwb是必须的。 回到pmem_init，初始化了Funcs系列函数，这些跟info里的一样的，不在写具体逻辑到这里了。最后pmem_os_init(&Is_pmem);这个就是第二篇里边的判断函数的初始化，暂时不细看了。 pmem_flush就是调用的flush_clwb,pmem_drain就是调用的memory_barrier,pmem_persist就是先flush后pmem_drain,pmem_memcpy就是先memmove_nodrain，然后drain，这里的特殊env控制就不管了。pmem_memcpy_nodrain就是只是少了pmem_drain这一步。pmem_memcpy_persist这个是不管env的肯定drain. flush_empty这个不干事，只是通知pmemcheck。 还剩最后一块memmove_nodrain = memmove_nodrain_avx512f_clwb。这个我之前看的时候，搜代码都搜不到，还好统看了一下代码文件，发现是个模板搞的。MEMCPY_TEMPLATE(avx512f, clwb, /* */)。 pmem_memcpy_nodrain调用的时候，flag传了一个0，所以没有flag的，调用的是memmove_movnt_avx512f_clwb。长度小于256单位应该是Byte吧，因为是传过来的len，使用memmove_mov_avx512f_clwb,其他情况是通过flag来决定的，这个可以通过pmem_memcpy可以传参数，属于最灵活的调用方式了，也可以指定是否pmem_drain。 memmove_mov_avx512f_clwb在libpmem2/x86_64/memcpy/memcpy_t_avx512f.c里，先通过if ((uintptr_t)dest - (uintptr_t)src >= len)来判断两块内存是否相交，然后选择不同方法。这里可以优化，想了想我要写的代码没有重叠内存，所以可以优化。看memmove_mov_avx512f_fw里主要就是不同长度选择使用不同函数就复制数据。我查看小数据的复制，是用的转成uint来进行赋值拷贝的。也用了循环展开优化数据复制。这里边的持久化用的pmem_clwb，这个是为已经对齐的地址准备的，看来我能想到的官方肯定都想到了啊。mov的指令都是使用的avx指令load和store. memmove_movnt_avx512f_clwb在memcpy_nt_avx512f.c里，这里也判断了数据重叠问题，但是没看懂的是这里需要flush，但是不需要barrier.我觉得不应该正好反过来吗。。这里用的是load和stream指令来移动数据，移动完跟想的一样是没有flush的，flush是为的开头结尾的小数据准备的。 两种移动数据都不需要barrier，可能是为了集中控制，把是否barrier的权限放到接口里决定。 现在具体看看也没有多少可以优化的，一个是flush的for循环，一个是memcpy的判断内存重叠的问题。不过每次减少两个判断，收益也不少了。再一个确认一下初始化是否算时间，把初始化的时间也优化了。 后期移植的时候又发现一个，在avx实现的拷贝过程中，是按2kb的数据块进行的ntstore。比赛最高1kb，所以这里可以去掉，从1kb开始判断就行了。

libpmem主要通过pmem_map_file封装来进行mmap的映射，首先通过util_file_get_type获取文件类型，主要区分文件是否存在，DAX设备文件。比赛用的fsdax，这个主要通过mmap来实现的寻址操作,挂载路径为/dev/pmem/。还有devdax，这个好像是给虚拟机分配的时候用这个模式，挂载路径为/dev/dax/。还有sector和raw模式。 文件支持的flag有(PMEM_FILE_CREATE|PMEM_FILE_EXCL|PMEM_FILE_SPARSE|PMEM_FILE_TMPFILE),dax设备支持的flag有(PMEM_FILE_CREATE|PMEM_FILE_SPARSE). 然后判断是dax后，判断len必须是0或者文件大小。open_flags默认有O_RDWR，如果flag有PMEM_FILE_CREATE则open_flags添加O_CREAT。后边判断传了len必须有PMEM_FILE_CREATE,len为0必须没有PMEM_FILE_CREATE.PMEM_FILE_TMPFILE必须有PMEM_FILE_CREATE.之后os_open(path, open_flags, mode)打开文件。如果flag带有PMEM_FILE_CREATE，则os_ftruncate文件，没有PMEM_FILE_SPARSE，则os_posix_fallocate(fd, 0, (os_off_t)len))文件。这里看不太懂，看手册这俩函数基本是等价的。如果没有PMEM_FILE_CREATE,则获取真是文件大小，重新复制len。 然后pmem_map_register，在pmem_posix.c里，调用util_map,传了MAP_SHARED。在common/mmap.c里 肯定有PROT_READ|PROT_WRITE，然后调用util_map_hint，这个主要就是确定mmap地址的，调试有参数可以固定虚地址的，这个看书看过。基本用不上。好像是通过mmap MAP_PRIVATE找一个mmap对齐的地址。 req_align为零，align = GIGABYTE。#define GIGABYTE ((uintptr_t)1 << 30)。这里脑袋有点浆糊了，不具体看就是找个一个对齐地址，然后后边用来mmap pmem文件使用，先这样吧。然后util_map_sync，地址是刚返回的地址，在这里mmap了。 然后复制len和is_pmemp。关闭fd，就结束了。pmem_is_pmem里边东西还挺多，有调试相关，乱七八糟一堆，主要是在初始化指定默认判断函数，然后在这里如果有env或者其他情况进行函数转换，然后掉函数看结果，不细看了，因为比赛肯定为pmem。 其实总结一下流程很简单，先打开文件，设置文件大小。然后mmap寻找一个对齐地址，最后真正mmap，返回。

参加了个阿里的kv数据库比赛，接触到持久化内存的概率，到现在对这里理解的也不是太深入，只管总结一下。看了官方的书，还有一些代码和官方视频，但是为了参加比赛，还是觉得研究一下代码。初步看了看发现能在比赛上优化的地方还挺多的，所以决定慢慢总结和移植一下。 持久化内存（Persistent Memory）我看网上好像概念已经老早就有了，我是第一次知道，也记不住讲不清。总的来说就是可以掉电不丢数据的内存，是嫌ssd慢了，又出来一个算是ssd和内存的中间层。还有两种模式，可以当普通内存用，相当于扩展普通内存的容量。或者当持久内存用，可以保证掉电不丢数据和快速的读写速度。 libpmem是intel开发的持久化内存开发组件（Persistent Memory Development Kit）里的一个库，属于底层库，libpmemobj等库都是在这基础上开发的。比赛用到，基本不考虑libpmemobj这库，集成太厉害了，libpmem我大体看了代码发现也可以修改移植，能优化不少。而且因为我c语言经验不多，看了源码后发现能学很多东西。所以决定阅读总结加移植代码。 大体的使用思路就是，基于系统调用mmap进行pmem的进程空间地址的映射，这里是内核原生支持了。所以这玩意应该出了很久了，才刚听说，感觉阿里应该属于用的比较早的。之后就跟正常使用内存一样了，而这些操作都是在用户空间，所以效率理论上还有优势，虽然本身速度赶不上内存。持久化操作需要将cpu cache里的数据踢出到内存(evict)，刷新到持久内存上。 基本情况就这样，下边看几个基础文件。学到很多代码 core/util.h util.c 这俩都是常用函数集合 #define force_inline __attribute__((always_inline)) inline #define NORETURN __attribute__((noreturn)) #define barrier() asm volatile("" ::: "memory") 第一个从名字就看出来是强制函数inline，第二个是有时候写的分支没有返回时编译器会有报错，这个可以告诉编译器不要报错。第三个是内存栅栏。 typedef uint64_t ua_uint64_t __attribute__((aligned(1))); 能够指定最少字节对齐数，受连接器限制，不会超过连接器大小。感觉没啥用，但是也可能以后用上，学到东西了。 util_setbit, util_clrbit这个是位操作，这个是会的 util_is_pow2, return v && !(v & (v - 1)); 判断是否是2的幂 __builtin_ctz，__builtin_clz，这个是判断一个数，从开头或者从结尾有多少个零的，厉害了。 其他的就没啥了，看看util.c util_is_zeroed检查内存为0，应该用不到，记录下。util_checksum_compute,这是是计算一块内存的checksum，已移植，不知道会不会比hash快，这个应该比hash准确，但是比赛还是讲究速度，到时候试试。算法好像是Fletcher64。 valgrind好像能模拟cpu环境，调试程序的，好像书里有写，没太看内容，先记录。 Mmap_align好像用来分配对齐的，这里不知道干啥的，先跳过记录。linux下直接分配的Pagesize = (unsigned long) sysconf(_SC_PAGESIZE) util_concat_str连接字符串，没用记录.util_localtime获取时间，没用记录 其他的基本用不上了，主要看书看到原理的地方，发现checksum相关内容，有用到，就搜了一下源码，看到这些代码。

linux内核使用许多likely和unlikely宏，这两个宏的内容为： #define likely(x) (__builtin_expect(!!(x), 1)) #define unlikely(x) (__builtin_expect(!!(x), 0)) 是用来告诉编译器，当前判断条件是否常用或者不常用。编译器根据提示，生成的二进制的代码流程会有相应改变，以达到让cpu尽可能的顺序执行的目的。gcc官方文档里说，使用-fprofile-arcs来进行实际的性能测试，说程序员对自己的程序的预测一般都是错误的。 然后我搜到是用gcov去做，使用了一下确实很直观。编译的时候，参数加上“-fprofile-arcs -ftest-coverage”。然后运行会生成 .gcda .gcno文件。用gcov source.c会生成相应代码的.gcov文件。vim编辑这些文件，就能看到源码形式的，每一行都执行了多少次。 这里说个疑问，前边说预测不准确，我当时看到那里还说真的是不准确。我之前就感觉明明会大概率走这个分支，然后加上提示后，速度却变慢了。但是当我用gcov去做完统计之后，发现确实很大很大概率走的那个分支，但是不知道为啥会变慢。我O2开反汇编发现内容是一样的，也可能是我测试的时候没开O2也许有不同。

想到了三种方式，但是结果跟自己预想的不太一样，具体也没有细想。 第一种方式就是char*类型的strcmp比较，这种比较容易想到。但是效率中等。 第二种方式是使用类型__uint128_t，这个是gcc给出的类型，应该可移植性不太高，这种方式速度最快，char*用的时间是差不多1.5倍。 第三种方式是使用sse，并行试试，_mm_xor_si128和_mm_test_all_zeros进行比较，但是速度是最慢的，可能涉及类型的转换，看指令也非常的多。我还以为会是最快的。 除了第三种慢的意外，我第一种还对比了第一个char就不相等的情况，这种特殊情况我以为第一种会快，没想到还是慢，跟之前速度差不多。 我特意看了一下第二种方式的实现方式：通过两个xor，分别对比8字节，然后通过or操作把两个对比结果合并，然后通过test指令判断合并的结果是否为0，test指令会修改ZF标志位，最后通过jne判断ZF标志位进行跳转。

最近看c底层相关的指令，操作，编码，多线程，磁盘文件读写相关的看的比较多。不经理永远不知道这里边的东西有多少，还有很多不易理解的。由于时间仓猝，本来想好好整理一下，作为一个总结，但还是决定只是记一个笔记，而且内容来自搜索引擎，有一部分不是看的官方文档解释等，可能不正确，而且没有写全。以后无聊的时候想起来再搞吧（感觉用不到以后不会再搞了） 先说为什么写这个文章，我碰到一个问题。多线程读写文件，然后单线程读取，线上后读取结果不一致。之前有过分步的测试，是没有问题的。 然后我排查原因，先从读入手，发现数据有问题，然后转到看写。写先通过单独打印几条日志，和对写入的数据错误判断，在某个函数。这时候，我打开编译的debug模式，就是能打印更详细的日志，然后发现问题没了，数据正常了。然后我就玩起了编译参数。发现打印日志就没事，不打印就出问题了，然后我就想到是编译器给我优化过头了，那时候还是开始02的优化。因为那个函数不涉及多线程的操作。然后我去掉 -DNDEBUG参数，然后用assert()判断出是哪一行出了问题。然后实验了几个方法，发现都是可以的，于是网上搜索资料，大体比较了一下这集中方式，选了一种。 1，把变量声明称volatile，主要功能是，编译器不会优化掉这个变量，然后变量的值不会存到寄存器，保证从内存中读取。看我的程序具体也看不出来，除非反汇编代码看看。也懒得看了。 2，__sync_synchronize (...)，This builtin issues a full memory barrier. 内存栅栏，这个是个硬件栅栏，效率相比下边不太高。 Memory Barrier （Memory Fence）分为两种，一种软件的，只对编译器起作用，一种是硬件的，看文章说是总线信号控制的，这个计算机组成结构没学好，也懒得细看。 下面几种跟linux内核中的相对应，没看源码，不知道对不对 #define mb() __asm__ __volatile__("mfence":::"memory")这个跟__sync_synchronize一个作用，是硬件的栅栏。 #define rmb() __asm__ __volatile__("lfence":::"memory")不允许将barrier之前的内存读取指令移到barrier之后 （release barrier） #define wmb() __asm__ __volatile__("sfence":::"memory")不允许将barrier之后的内存读取指令移到barrier之前（acquire barrier） #define barrier() __asm__ __volatile__("":::"memory") barrier()是软栅栏， rmb wmb好像分单处理器和多处理器不一样，单处理器为软栅栏。 期间写的程序也有好多cas操作，atomic原子操作，编译器主要用的gcc的，然后直接用的gcc的，官方地址： https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

perf工具应该都听说过，我也试了一把，感觉很好很强大。 先使用sudo perf stat ./a.out命令，查看一下性能统计信息。结果展示为： Performance counter stats for './a.out': 2,740.62 msec task-clock # 3.903 CPUs utilized 39 context-switches # 0.014 K/sec 2 cpu-migrations # 0.001 K/sec 128,974 page-faults # 0.047 M/sec 10,394,863,898 cycles # 3.793 GHz 14,055,693,753 instructions # 1.35 insn per cycle 2,865,438,627 branches # 1045.545 M/sec 17,411,072 branch-misses # 0.61% of all branches 0.702237190 seconds time elapsed 2.533414000 seconds user 0.208445000 seconds sys 因为程序基本跑内存的，这里cpu使用比较高，就是开始的时候读了文件。四个线程高达3.9的使用率 context-switches 是进程上下文切换，这个不知道为啥，可能我系统跑的东西太多了。 CPU-migrations 这个是cpu迁移次数，没办法避免吧，程序跑的多，或者需要cpu绑定。 page-faults 这个感觉有点高，不知道为啥，我这还没涉及文件读写相关，已经这么高了。 branch-misses 这个感觉也比较高，看看使用分支预测改善一下，能不能好。这个需要对比一下。 获取程序的cpu运行时间统计，sudo perf record -e cpu-clock ./a.out，命令会生成perf.data文件，使用perf report查看报告 下边还有个直接展示的高级货，叫做火焰图。用perl写的，感觉好强大，以后可以稍微研究一下怎么生成的。 需要先clone下代码来：git clone --depth=1 https://github.com/brendangregg/FlameGraph.git 上一步收集信息的时候必须加-g参数，用来收集堆栈信息，不然后边生成图像的时候会报错。 sudo perf record -g ./a.out 数据解析 sudo perf script -i perf.data &> perf.unfold 数据折叠 ./stackcollapse-perf.pl perf.unfold &> perf.folded 图像生成 ./flamegraph.pl perf.folded > perf.svg 生成的图片用chrome查看是有效果的，我用ubuntu自带的图片查看软件，发现不能交互。 我发现对于递归程序，展示的不太友好，虽然能从调用栈中获取到递归深度，但是调用的函数差不多都放到递归最里边了，可能是取样的问题嘛，，

Valgrind可以模拟cpu执行你的程序，然后给出内存使用或者程序错误信息。之前只使用过gdb来调试程序逻辑错误，现在准备多看几个，包括性能方面的调试。 安装直接使用的apt源安装的，使用也比较简单。直接valgrind ./a.out允许程序，运行过程中会给出程序建议。 这个程序我有一个一百万长度的uint64的数组，提示了"Invalid write of size 8"的错误，Warning: client switching stacks? SP change: 0x6c55ef0 --> 0x64b4c60 to suppress, use: --max-stackframe=8000144 or greater 我搜了一下发现说是栈空间消耗太大，我改成calloc，两个错误提示都没了。 ==15130== HEAP SUMMARY: ==15130== in use at exit: 457,122,934 bytes in 4,659,095 blocks ==15130== total heap usage: 4,659,118 allocs, 23 frees, 457,166,878 bytes allocated ==15130== ==15130== LEAK SUMMARY: ==15130== definitely lost: 48,850,904 bytes in 177,241 blocks ==15130== indirectly lost: 400,271,992 bytes in 4,481,851 blocks ==15130== possibly lost: 8,000,000 bytes in 1 blocks ==15130== still reachable: 38 bytes in 2 blocks ==15130== suppressed: 0 bytes in 0 blocks ==15130== Rerun with --leak-check=full to see details of leaked memory 最后有内存统计信息，malloc后没有free的内存都会在统计。下面这段解释是我摘自网上的，我感觉不太准确（可能是valgrind检测的就不太准确），但是个参考。 Memcheck将内存泄露分为两种，一种是可能的内存泄露（Possibly lost），另外一种是确定的内存泄露（Definitely lost）。 Possibly lost 是指仍然存在某个指针能够访问某块内存，但该指针指向的已经不是该内存首地址。Definitely lost 是指已经不能够访问这块内存。而Definitely lost又分为两种：直接的（direct）和间接的（indirect）。直接和间接的区别就是，直接是没有任何指针指向该内存，间接是指指向该内存的指针都位于内存泄露处。在上述的例子中，根节点是directly lost，而其他节点是indirectly lost。 possibly lost: 8,000,000 bytes in 1 blocks这个就是我那个一百万的数组malloc后没有free释放的，然后我free后，这行就没了。但我指针没修改，是个多线程的内存申请，但是只检测出一个来。四个线程没一个都malloc了。 Valgrind User Manual写的很详细，好多功能，一时半会也试不完。先体验一把，有需求再说。

写个uint64_t的程序，涉及大小端的转换。 uint64_t x = 0x0123456789ABCDEF; On a 32-bit little-endian processor, it will appear in memory as EF CD AB 89 67 45 23 01 On a 64-bit little-endian processor, it will appear in memory as EF CD AB 89 67 45 23 01. On a 32-bit big-endian processor, it will appear in memory as 01 23 45 67 89 AB CD EF. On a 64-bit big-endian processor, it will appear in memory as 01 23 45 67 89 AB CD EF. 转换涉及#include uint64_t htobe64(uint64_t host_64bits); uint64_t htole64(uint64_t host_64bits); uint64_t be64toh(uint64_t big_endian_64bits); uint64_t le64toh(uint64_t little_endian_64bits); The functions with names of the form "htobenn" convert from host byte order to big-endian order. The functions with names of the form "htolenn" convert from host byte order to little-endian order. The functions with names of the form "benntoh" convert from big-endian order to host byte order. The functions with names of the form "lenntoh" convert from little-endian order to host byte order.、 看了一下头文件，判断是否是小端序，然后采用不同转换方式。涉及bits/byteswap.h头文件。没时间细看了，先记录，以后有时间再看。

零拷贝不是一个新技术了，之前一直接触不到这么底层的技术，最近看的比较多，所以从代码上研究了一下。 在应用程序做数据传输等操作涉及系统调用，而为了提高性能，就是从减少系统调用次数和减少内核空间和用户空间的数据拷贝次数入手的。 具体的我也没看代码，都是从网上总结学来的。 像mmap方式，是减少了内核空间和用户空间的数据拷贝，使用映射还是指针的能够共享内核空间。但涉及比如把一个文件内容通过网络发送的操作，还涉及内核空间的数据拷贝。 sendfile和splice就是解决内核空间的数据copy的，我看linux手册是page buffer指针的复制，所以没有做数据的copy。指针是通过pipe buffer存储的。 ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count); ssize_t sendfile64(int out_fd, int in_fd, loff_t *offset, size_t count); 这俩的区别是sendfile64适合传送大文件，offset类型也决定了适合做大文件的偏移用。但不仅仅是这里，看源码，sendfile指定offset之后，会设置复制的最大值为MAX_NON_LFS，这个值我没找，但是类型初步判断加文档判断来说，最大不到2G(看文档是不到2G).(后来还是去找了，#define MAX_NON_LFS ((1UL<<31) - 1), 文档写的是0x7ffff000 (2,147,479,552) ) 我看了一下函数实现的源码，尽量只看流程，不去细看实现，看看优化能注意的点。 通过看源码，发现最好是不指定offset这个参数，因为指定这个参数后，会多两次的内核函数调用，涉及用户空间和内核空间的数据拷贝，get_user，put_user，copy_from_user。然后统一调用do_sendfile函数。而如果offset为NULL的时候，在do_sendfile函数里，是通过文件的offset来复制数据的。所以尽量不指定offset是最好的，但如果提前设置文件offset还要涉及系统调用，具体权衡就不知道了。 在do_sendfile里没啥可以细讲的，流程大部分能猜到什么意思。主要最后调用do_splice_direct。 这里有个疑问就是，为什么offset要用指针类型，而不能直接传一个数字，我猜可能是历史遗留问题吧，可能接口没办法变动了。 do_splice_direct函数跟splice是在一个文件，可以差不多猜到，俩的实现原理是一样的了。 do_splice_direct里splice_desc sd定义输出文件的信息。 然后调用了splice_direct_to_actor，这里有一个pipe = current->splice_pipe;这个pipe是在linux的进程管理的pcb(task_struct)中，这里边有一个splice_pipe，用来存储splice()上一次使用的过的pipe。这里是判断如果current->splice_pipe不存在，就新创建一个，然后缓存到current->splice_pipe。然后调用do_splice_to,流程跟splice复制文件到pipe的流程差不多。 splice里直接调用do_splice,这里分三种情况，in和out都有pipe时，调用splice_pipe_to_pipe；in为pipe时调用do_splice_from，out为pipe时调用do_splice_to。这俩单个的也涉及offset的用户空间和内核空间复制的问题。 do_splice_from我直接看的default_file_splice_write，调用splice_from_pipe。里边初始化splice_desc sd，存了要写的文件信息，调用__splice_from_pipe，splice_from_pipe_feed里是将pip内容关联复制到文件。 do_splice_to也是直接看default_file_splice_read，初始化一个结构体splice_pipe_desc spd，看起来是存储pagebuffer信息的，具体看不太懂，也没去查，初始化spd空间，kernel_readv应该是用来吧in的page buffer内容的指针存入spd了，nr_pages_max = PIPE_DEF_BUFFERS这个值是16(看文档在内核版本2.6.35之后，可以通过fcntl的F_GETPIPE_SZ和F_SETPIPE_SZ进行设置)，好像是最大页数，最后调用splice_to_pipe(pipe, &spd);好像就是从spd里刚保存的页信息关联复制数据到pipe。 vmsplice支持从用户空间复制数据到pipe，反方向的复制也支持，但是是内存数据的真复制。 tee复制管道内容，从一个复制到另一个 总结一下就是，文件的传输使用sendfile比较好，他会缓存pipe，并且少一次的系统调用。如果用splice，需要先从一个文件到pipe，然后pipe到另一个文件，虽然也没有真正复制，但是系统调用是两次。 splice可以实现类似代理服务器数据转发的功能，使用一个pipe连接两个socket。 上边说的都是PIPESIZE。在Linux 2.6.11之前，PIPESIZE和PIPEBUF实际上是一样的。在这之后，Linux重新实现了一个管道缓存，并将它与写操作的PIPEBUF实现成了不同的概念，形成了一个默认长度为65536字节的PIPESIZE，而PIPEBUF只影响相关读写操作的原子性，一般为page大小，内核每次操作量。PIPESIZE的最大值在/proc/sys/fs/pipe-max-size里进行设置。从Linux 2.6.35之后，在fcntl系统调用方法中实现了F_GETPIPE_SZ和F_SETPIPE_SZ操作，来分别查看当前管道容量和设置管道容量。