Re: [REGRESSION] tmpfs: flistxattr(fd) small-list slowdown after simple_xattrs rhashtable conversion

[Chengfeng Lin]

Hi Honza,

Sorry for the delayed reply.

Thanks for pointing me to this. The released-kernel point in my original
report was Linux 7.1.0 (uname -r: 7.1.0-bm-7.1).

I have now tested this on bare metal, and I can no longer observe the slowdown
after 1e7cd8a53b72 ("simpe_xattr: use per-sb cache").

I used the following test order, with a fresh boot for each point:

  7.0.14 A -> 7.1.3 -> 076e5cef28e2 parent A ->
  1e7cd8a53b72 child -> 076e5cef28e2 parent B -> 7.0.14 B

The 076e and 1e7 kernels are the exact direct parent/child pair. The v7.1.3
point also does not contain 1e7; I included it as an updated check of the 7.1
stable line, not as the patched kernel.

The workload was the same narrow tmpfs case from my report: one user xattr and
repeated flistxattr(fd, buffer, 8192). Each point had 3 warm-up rounds
followed by 15 measured rounds of 1,048,576 calls. The primary results in
ns/op (lower is better) were:

  point       mean ns/op
  7.0.14 A       218.202
  7.1.3          336.140
  parent A       327.037
  1e7 child      208.447
  parent B       323.640
  7.0.14 B       217.007

Using the midpoint of each pair of surrounding controls:

  7.1.3 vs 7.0 midpoint:        +54.47%
  076e parent vs 7.0 midpoint:  +49.51%
  1e7 child vs parent midpoint: -35.93%
  1e7 child vs 7.0 midpoint:     -4.21%

The two 7.0 controls drifted by -0.55%, and the two parent controls by -1.04%.
All 90 measured rows passed the semantic checks, with the expected returned
length and no unexpected results. Dropping the first measured round from every
point produced essentially the same deltas.

The machine was an Intel Core i7-12700KF system with 32 GiB RAM. The benchmark
was pinned to P-core CPU 2, with both the scaling governor and
energy_performance_preference set to performance, Turbo disabled, and
preempt=none. The parent and child were built from the exact commits with the
same normalized config, GCC 15.2.0 toolchain, and Kbuild metadata.

So the answer to question 1 is no: after 1e7cd8a53b72 I do not see a remaining
slowdown relative to 7.0 in this workload. Since the condition in question 2
does not hold, I did not collect post-fix profiles. For this specific syscall
microbenchmark, the commit appears to fully address the reported regression. I
have not tested application-level impact or other filesystems and xattr-list
shapes.

The compact validation summary and CSVs are available here:

  https://github.com/lcf0399/linux-regression-evidence/tree/1dae4daafc8dc93bd081b7ab71756f864c36a0b0/tmpfs-flistxattr-small-list/fix-validation

Tested-by: Chengfeng Lin <lin2530632123@xxxxxxxxx>

Thanks,
Chengfeng