On 8/27/25 5:00 PM, Christoph Hellwig wrote: > On Wed, Aug 27, 2025 at 09:52:21AM +0200, Sebastian Andrzej Siewior wrote: >>> this for you, you could also reproduce it before by say doing a large >>> direct I/O read. >> >> On a kernel without that commit in question? Booting Debian's current >> v6.12 and >> | dd if=vmlinux.o of=/dev/null bs=1G count=1 iflag=direct >> >> works like a charm. According to strace it does >> | openat(AT_FDCWD, "vmlinux.o", O_RDONLY|O_DIRECT) = 3 >> | dup2(3, 0) = 0 >> | lseek(0, 0, SEEK_CUR) = 0 >> | read(0, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\1\0>\0\1\0\0\0\0\0\0\0\0\0\0\0"..., 1073741824) = 841980992 >> >> so it should be what you asked for. Asked for 1G, got ~800M. > > This is probably splitting thing up into multiple bios because your > output memory is fragmented. You'd have to do it into hugetlbfs or > vma otherwise backed by very larger folios. and also need: echo 4096 > /sys/block/sdX/queue/max_sectors_kb or some large number. But given that commit 345c5091ffec sets the default to 4MiB, I/Os are split to 4M and trigger the issue. So there is likely a cut-off command size < 4M where things stop working with this adapter. -- Damien Le Moal Western Digital Research
