| 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
| ||
|
Date: Tue, 17 Aug 2010 16:54:03 +0200 From: Andi Kleen <andi@...stfloor.org> To: "Patrick J. LoPresti" <lopresti@...il.com> Cc: linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: Proposal: Use hi-res clock for file timestamps "Patrick J. LoPresti" <lopresti@...il.com> writes: > > 1) Anybody who cares about file system performance is already using > "noatime" or "relatime", which mitigates the hit greatly. Consider mtime. > If the above patch is too slow for some architectures, how about > making it a configuration option? Call it "CONFIG_1980S_FILE_TICK", > have it default to YES on the architectures that care and NO on > anything remotely modern and sane. > > OK that's my proposal. Bash away. I suspect it will be a performance disaster on x86 for VFS intensive applications on capable file systems. VFS is very performance critical. These checks lurk on unexpected places too, e.g. on /dev access. Even TSC is much slower than just reading the variable. Also you should check if the file system granuality even supports it, it's completely wasted on a ext3 for example. Maybe as a optional sysctl, default to off. -Andi -- ak@...ux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists