| 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: <m2pql2c0qz.fsf@firstfloor.org> Date: Thu, 21 Jul 2011 23:01:24 -0700 From: Andi Kleen <andi@...stfloor.org> To: Matt Mackall <mpm@...enic.com> Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: Nanosecond fs timestamp support: sad Matt Mackall <mpm@...enic.com> writes: > This means I can touch a file something like 70k times per second and > get only 300 distinct timestamps on my laptop. And only 100 distinct > timestamps on a typical distro server kernel. You should use the inode generation number if you really want to see every update. > Meanwhile, I can call gettimeofday 35M times per second and get ~1M > distinct responses. They key word here is "I". > Given that we can do gettimeofday three orders of magnitude faster than > we can do file transactions and it has four orders of magnitude better > resolution, shouldn't we be using it for filesystem time when > sb->s_time_gran is less than 1/HZ? Some systems have a quite slow gettimeofday() That was the primary motivation for using jiffies. Also adding more granuality makes it more expensive, because there's additional work every time it changes. Even jiffies already caused regressions. -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