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:	Mon, 6 Apr 2009 15:13:30 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	linux-kernel@...r.kernel.org
Cc:	tytso@....edu, torvalds@...ux-foundation.org
Subject: Re: [PATCH 0/8][RFC] IO latency/throughput fixes

On Mon, Apr 06 2009, Jens Axboe wrote:
> On Mon, Apr 06 2009, Jens Axboe wrote:
> > Hi,
> > 
> > This is a set of patches that I worked on today in the hopes
> > of furthering the latency goals and at least fixing some of
> > the write regression with fwrite + fsync that current -git
> > is suffering from.
> > 
> > I haven't done any latency tests yet, I'm just tossing this
> > out there so we can collaborate on improving things. What I
> > did test was the silly fwrite() + fsync() loop test, which
> > is a LOT slower in current -git that it used to be. The test
> > is basically:
> > 
> > 	while (nr--) {
> > 		f = fopen();
> > 		fprintf(f, "Some data here\n");
> > 		fsync(fileno(f));
> > 		fclose(f);
> > 	}
> > 
> > which (for nr == 2000) takes 16 seconds in -git, completes
> > in 0.9s with the patches.
> 
> Ran the fsync-tester [1]. Drive is a 3-4 years old SATA drive, fs is
> ext3/writeback. IO scheduler is CFQ.
> 
> fsync time: 0.0402s
> fsync time: 0.6572s
> fsync time: 0.3187s
> fsync time: 0.2901s
> fsync time: 0.1478s
> fsync time: 0.4158s
> fsync time: 0.2815s
> fsync time: 0.3216s
> fsync time: 0.1604s
> fsync time: 0.1929s
> fsync time: 0.2413s
> fsync time: 0.2138s
> fsync time: 0.2441s
> fsync time: 0.2785s
> fsync time: 0.2640s
> 
> And with Linus torture dd running in the background:
> 
> fsync time: 0.0109s
> fsync time: 0.5236s
> fsync time: 1.2108s
> fsync time: 0.2999s
> fsync time: 1.5286s
> fsync time: 0.2549s
> fsync time: 0.4164s
> fsync time: 1.1586s
> fsync time: 1.6630s
> fsync time: 0.6949s
> fsync time: 1.0102s
> fsync time: 0.3715s
> fsync time: 0.6553s

And here is that latter test again with NCQ disabled on the drive:

fsync time: 0.0092s
fsync time: 0.7815s
fsync time: 0.6490s
fsync time: 0.7894s
fsync time: 0.5385s
fsync time: 0.6598s
fsync time: 0.7701s
fsync time: 0.2155s
fsync time: 0.0901s
fsync time: 0.2765s
fsync time: 0.2879s
fsync time: 0.2882s
fsync time: 0.2457s
fsync time: 0.4319s
fsync time: 0.3752s

It stays nicely below 1s.

-- 
Jens Axboe

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ