linux-kernel - Re: [PATCH 00/37] Permit filesystem local caching

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Feb 2008 23:33:53 +0000
From:	David Howells <dhowells@...hat.com>
To:	unlisted-recipients:; (no To-header on input)
Cc:	dhowells@...hat.com, Daniel Phillips <phillips@...nq.net>,
	Trond.Myklebust@...app.com, chuck.lever@...cle.com,
	casey@...aufler-ca.com, nfsv4@...ux-nfs.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	selinux@...ho.nsa.gov, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 00/37] Permit filesystem local caching

David Howells <dhowells@...hat.com> wrote:

> > Have you got before/after benchmark results?
> 
> See attached.

Attached here are results using BTRFS (patched so that it'll work at all)
rather than Ext3 on the client on the partition backing the cache.

Note that I didn't bother redoing the tests that didn't involve a cache as the
choice of filesystem backing the cache should have no bearing on the result.

Generally, completely cold caches shouldn't show much variation as all the
writing can be done completely asynchronously, provided the client doesn't
fill its RAM.

The interesting case is where the disk cache is warm, but the pagecache is
cold (ie: just after a reboot after filling the caches).  Here, for the two
big files case, BTRFS appears quite a bit better than Ext3, showing a 21%
reduction in time for the smaller case and a 13% reduction for the larger
case.

For the many small/medium files case, BTRFS performed significantly better
(15% reduction in time) in the case where the caches were completely cold.
I'm not sure why, though - perhaps because it doesn't execute a write_begin()
stage during the write_one_page() call and thus doesn't go allocating disk
blocks to back the data, but instead allocates them later.

More surprising is that BTRFS performed significantly worse (15% increase in
time) in the case where the cache on disk was fully populated and then the
machine had been rebooted to clear the pagecaches.

It's important to note that I've only run each test once apiece, so the
numbers should be taken with a modicum of salt (bad statistics and all that).

David
---
===========================
FEW BIG FILES TEST ON BTRFS
===========================

Completely cold caches:

	[root@...romeda ~]# time cat /warthog/bigfile >/dev/null
	real    0m2.124s
	user    0m0.000s
	sys     0m1.260s
	[root@...romeda ~]# time cat /warthog/biggerfile >/dev/null
	real    0m4.538s
	user    0m0.000s
	sys     0m2.624s

Warm NFS pagecache:

	[root@...romeda ~]# time cat /warthog/bigfile >/dev/null
	real    0m0.061s
	user    0m0.000s
	sys     0m0.064s
	[root@...romeda ~]# time cat /warthog/biggerfile >/dev/null
	real    0m0.118s
	user    0m0.000s
	sys     0m0.116s

Warm BTRFS pagecache, cold NFS pagecache:

	[root@...romeda ~]# time cat /warthog/bigfile >/dev/null
	real    0m0.189s
	user    0m0.000s
	sys     0m0.188s
	[root@...romeda ~]# time cat /warthog/biggerfile >/dev/null
	real    0m0.369s
	user    0m0.000s
	sys     0m0.368s

Warm on-disk cache, cold pagecaches:

	[root@...romeda ~]# time cat /warthog/bigfile >/dev/null
	real    0m1.540s
	user    0m0.000s
	sys     0m1.440s
	[root@...romeda ~]# time cat /warthog/biggerfile >/dev/null
	real    0m3.132s
	user    0m0.000s
	sys     0m1.724s

============================================
MANY SMALL/MEDIUM FILE READING TEST ON BTRFS
============================================

Completely cold caches:

	[root@...romeda ~]# time tar cf - /warthog/aaa >/dev/zero
	real    0m31.838s
	user    0m0.192s
	sys     0m6.076s

Warm NFS pagecache:

	[root@...romeda ~]# time tar cf - /warthog/aaa >/dev/zero
	real    0m14.841s
	user    0m0.148s
	sys     0m4.988s

Warm BTRFS pagecache, cold NFS pagecache:

	[root@...romeda ~]# time tar cf - /warthog/aaa >/dev/zero
	real    0m16.773s
	user    0m0.148s
	sys     0m5.512s

Warm on-disk cache, cold pagecaches:

	[root@...romeda ~]# time tar cf - /warthog/aaa >/dev/zero
	real    2m12.527s
	user    0m0.080s
	sys     0m2.908s

--
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/