| 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: Thu, 15 Aug 2013 14:29:30 +1000 From: Dave Chinner <david@...morbit.com> To: Andi Kleen <ak@...ux.intel.com> Cc: Dave Hansen <dave.hansen@...ux.intel.com>, linux-fsdevel@...r.kernel.org, xfs@....sgi.com, linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>, LKML <linux-kernel@...r.kernel.org>, Tim Chen <tim.c.chen@...ux.intel.com>, Andy Lutomirski <luto@...capital.net> Subject: Re: page fault scalability (ext3, ext4, xfs) On Wed, Aug 14, 2013 at 07:24:01PM -0700, Andi Kleen wrote: > > And FWIW, it's no secret that XFS has more per-operation overhead > > than ext4 through the write path when it comes to allocation, so > > it's no surprise that on a workload that is highly dependent on > > allocation overhead that ext4 is a bit faster.... > > This cannot explain a worse scaling curve though? The scaling curve is pretty much identical. The difference in performance will be the overhead of timestamp updates through the transaction subsystems of the filesystems. > w-i-s is all about scaling. Sure, but scaling *what*? It's spending all it's time in the filesystem through the .page_mkwrite path. It's not a page fault scaling test - it's a filesystem overwrite test that uses mmap. Indeed, I bet if you replace the mmap() with a write(fd, buf, 4096) loop, you'd get almost identical behaviour from the filesystems. Cheers, Dave. -- Dave Chinner david@...morbit.com -- 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