linux-kernel - RE: Mainline kernel OLTP performance update

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]

Message-ID: <CAC4B8726E86A142B27A9E9A2F2F1247AB7A82C5@rrsmsx505.amr.corp.intel.com>
Date:	Wed, 6 May 2009 12:12:02 -0600
From:	"Wilcox, Matthew R" <matthew.r.wilcox@...el.com>
To:	"Styner, Douglas W" <douglas.w.styner@...el.com>,
	Anirban Chakraborty <anirban.chakraborty@...gic.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	"Tripathi, Sharad C" <sharad.c.tripathi@...el.com>,
	"arjan@...ux.intel.com" <arjan@...ux.intel.com>,
	"Kleen, Andi" <andi.kleen@...el.com>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"Ma, Chinang" <chinang.ma@...el.com>,
	"Wang, Peter Xihong" <peter.xihong.wang@...el.com>,
	"Nueckel, Hubert" <hubert.nueckel@...el.com>,
	"Recalde, Luis F" <luis.f.recalde@...el.com>,
	"Nelson, Doug" <doug.nelson@...el.com>,
	"Cheng, Wu-sun" <wu-sun.cheng@...el.com>,
	"Prickett, Terry O" <terry.o.prickett@...el.com>,
	"Shunmuganathan, Rajalakshmi" <rajalakshmi.shunmuganathan@...el.com>,
	"Garg, Anil K" <anil.k.garg@...el.com>,
	"Chilukuri, Harita" <harita.chilukuri@...el.com>,
	"chris.mason@...cle.com" <chris.mason@...cle.com>
Subject: RE: Mainline kernel OLTP performance update

That's a more accurate simulation of our workload, but Anirban's setup doesn't have nearly as many spindles as ours, so he won't do as many IOPS and may not see the problem.

All I'm trying to do is get something that will show the problem on his setup, and I think sequential IO is going to be the right answer here.  I could easily be wrong.

Neither FIO nor dd is going to have the cache behaviour of the database (maybe Orion does?)  As far as I can tell, we come to the kernel cache-cold for every IO simply because the database uses as many cache entries as it can.  We could write a little program to just thrash through cachelines, or just run gcc at the same time as this -- apparently gcc will happily chew through all the cache it can too.

> -----Original Message-----
> From: Styner, Douglas W
> Sent: Wednesday, May 06, 2009 11:05 AM
> To: Wilcox, Matthew R; Anirban Chakraborty; linux-kernel@...r.kernel.org
> Cc: Tripathi, Sharad C; arjan@...ux.intel.com; Kleen, Andi; Siddha, Suresh
> B; Ma, Chinang; Wang, Peter Xihong; Nueckel, Hubert; Recalde, Luis F;
> Nelson, Doug; Cheng, Wu-sun; Prickett, Terry O; Shunmuganathan,
> Rajalakshmi; Garg, Anil K; Chilukuri, Harita; chris.mason@...cle.com
> Subject: RE: Mainline kernel OLTP performance update
> 
> Wilcox, Matthew R writes:
> >I'm not sure that Orion is going to give useful results in your hardware
> >setup.  I suspect you don't have enough spindles to get the IO rates that
> >are required to see the problem.  How about doing lots of contiguous I/O
> >instead?  Something as simple as:
> >
> >for i in sda sdb sdc (repeat ad nauseam); do \
> >	dd if=/dev/$i of=/dev/null bs=4k iflag=direct & \
> >done
> >
> 
> A better workload emulator would be to use FIO to generate ~60%/40%
> reads/writes with ~90-95% random i/o using 2k blksize.  There is some
> sequential writing in our workload but only to a log file and there is not
> much activity there.