lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20120413182227.GY17822@one.firstfloor.org> Date: Fri, 13 Apr 2012 20:22:27 +0200 From: Andi Kleen <andi@...stfloor.org> To: Ted Ts'o <tytso@....edu> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Andi Kleen <andi@...stfloor.org>, Vivek Haldar <haldar@...gle.com>, Andreas Dilger <adilger@...ger.ca>, linux-ext4@...r.kernel.org, tim.c.chen@...ux.intel.com Subject: Re: [RFC, PATCH] Avoid hot statistics cache line in ext4 extent cache > 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@...ux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists