CC @acln0

If 32K is better than 4M on your system, perhaps we should just use that everywhere.

Seconded @ianlancetaylor if there is a better value, let's make it the default rather than a configuration option.

If 32K is better than 4M on your system, perhaps we should just use that everywhere.

In principle, I don't see why not, but I would need to run benchmarks to make sure that the change doesn't represent a regression for code that transfers a huge volume of data per unit of time through splice (the kind of systems that saturate links). Such code was the motivation for introducing the splice code in the first place, and a regression would be undesirable. If there is a singular better value, then, of course, that should be the default. Trying to sneak configuration down to the splice code seems to be prohibitively difficult to me anyway, so I think that option is off the table.

I do wonder why a maximum transfer size of 4M per splice round makes things significantly slower, though. We also have a large round size here:

Should we change this one too? Or is this one different because it's copy_file_range and not splice?

Even if we changed the 4M to 32K today, the change wouldn't make it into the 1.15 tree, so I think it would be better to investigate it properly, by reading kernel source code, running more benchmarks, and so forth. I am going to do that at some point in the 1.16 development cycle.

@march1993
Sorry for the trouble. If you don't want to maintain a patched Go tree for a cycle until this is sorted out, try using, instead of io.Copy(dst, src), io.Copy(struct{ io.Writer }{dst}, src). This turns off the splice code and gives you the buffer size you want, at the cost of a little extra copying.

But while you are at it, and have patched your tree already, can you try a few additional intermediate transfer sizes and report the performance you observe, please? Perhaps 64K, 256K, and 1M? Thanks.

The length should be under MAX_RW_COUNT which based on PAGE_MASK

https://github.com/torvalds/linux/blob/d76913908102044f14381df865bb74df17a538cb/fs/splice.c#L783-L784

I can send a CL for this and done some tests on my rpi etc.

Change https://go.dev/cl/425051 mentions this issue: internal/poll: optimize the maximum amount that can be transferred by one splice(2) call

@march1993 What is the contents of the file /proc/sys/fs/pipe-max-size on your system? Thanks.

@march1993 What is the contents of the file /proc/sys/fs/pipe-max-size on your system? Thanks.

It was 1048576.

Were you transferring a mass of data via splice(2) or small amount of data？and what's your kernel version? thanks.
@march1993

Were you transferring a mass of data via splice(2) or small amount of data？and what's your kernel version? thanks. @march1993

A mass of data. The kernel version was 5.4.154.