> I think Andi cited the wrong commit. The commit in question is > 77f4135f2a219a2127be6cc1208c42e6175b11dd, which first showed up in > 2.6.39. If you have a very fast (PCIe-attached would be required I I don't think it was a highend IO device. This already hits for buffered IO I think. > I'm willing to push commit to you to remove the counters for now, and > we'll probably add it back later using percpu counters if you think > it's worth making a change at this time --- or if Andi can explain why > he's treating this with a high degree of urgency. Is there some > common use case that I'm missing which is being very badly impacted > with this cache-line thrashing? Well IO writes is a pretty common use case. On a smaller system it's likely not ~30%, but likely a drag too. And we normally try to fix scalability regressions each release. Otherwise things will just get worse and worse over time. Scalability is unfortunately quite fragile and needs constant attention. Every bad hot cache line can break it. So yes I would like this to be reverted for the release. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- 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
