> > Can we please revert fix it or revert
> > 556b27abf73833923d5cd4be80006292e1b31662 before release.
>
> That commit ID doesn't make any sense, and doesn't seem to have
> anything to do with any statistics counters that your email talks
> about. So regardless, you'd need to explain why that commit causes the
> problems you talk about, I'm not going to revert a random commit that
> doesn't even look what you describe.
Sorry correct problematic commit is
commit 77f4135f2a219a2127be6cc1208c42e6175b11dd
Author: Vivek Haldar <haldar@xxxxxxxxxx>
Date: Sun May 22 21:24:16 2011 -0400
ext4: count hits/misses of extent cache and expose in sysfs
The problem is that every IO operation in ext4 bangs on this super block
cache line when it checks the extent cache and then updates the hit/miss
count. On a system with more than two sockets this is very costly
in terms of interconnect traffic under high IO load.
A straight revert has a minor conflict on a trace statement that
was added later.
-Andi
Original patch:
commit 77f4135f2a219a2127be6cc1208c42e6175b11dd
Author: Vivek Haldar <haldar@xxxxxxxxxx>
Date: Sun May 22 21:24:16 2011 -0400
ext4: count hits/misses of extent cache and expose in sysfs
The number of hits and misses for each filesystem is exposed in
/sys/fs/ext4/<dev>/extent_cache_{hits, misses}.
Tested: fsstress, manual checks.
Signed-off-by: Vivek Haldar <haldar@xxxxxxxxxx>
Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
