Re: [PATCH 0/5] fuse: report a request refused for a live nodeid
Aaron Paterson <[email protected]>
| Newsgroups | dev.linux.lists.virtualization,dev.linux.lists.fuse-devel,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest |
|---|---|
| Message-ID | <[email protected]> |
The measurements in the cover letter were taken on 6.18.5. I have now run the same comparison on current mainline, so the numbers sit on the tree the series is posted against: v7.2-15794-g1b78070aaef6, inside the 7.3 merge window. Both kernels come from the mainline git tree directly rather than from applying the patches at build time. The unpatched arm is that commit as it stands; the patched arm is the same commit with these five applied. So the only difference between the two kernels is the series as posted. arm fs/fuse virtio_fs opens refused A stock stock 315076 22646 (7.2%) D patched patched 407169 0 Every refusal on arm A is the contradiction the probe exists to report: open answered ENOENT while stat on the same path a moment later still described the file. On arm D there are none. The refusal rate is lower here than the 14.0% the cover letter reports for 6.18.5. It is a race, so the rate moves with load and with how fast the guest gets through its loop, and the arms above were taken while the host was busy building the other kernel. What does not move is which side of zero each arm lands on. The probe is the one described in the cover letter: one process replaces a file by rename while another opens the same name as fast as it can. The server is Apple's Virtualization virtio-fs, which releases an inode as soon as a rename displaces the name it was looked up by, and is what makes the refusal observable at all.