Date:	Tue, 09 Oct 2012 11:41:16 +0200
From:	Viktor Nagy <viktor.nagy@...4games.com>
To:	linux-kernel@...r.kernel.org
Subject: Linux 3.0+ Disk performance problem - wrong pdflush behaviour

Hello,

Since Kernel version 3.0 pdflush blocks writes even the dirty bytes are 
well below /proc/sys/vm/dirty_bytes or /proc/sys/vm/dirty_ratio.
The kernel 2.6.39 works nice.

How this hurt us in the real life: We have a very high performance game 
server where the MySQL have to do many writes along the reads. All 
writes and reads are very simple and have to be very quick. If we run 
the system with Linux 3.2 we get unacceptable performance. Now we are 
stuck with 2.6.32 kernel here because this problem.

I attach the test program wrote by me which shows the problem. The 
program just writes blocks continously to random position to a given big 
file. The write rate limited to 100 MByte/s. In a well-working kernel it 
have to run with constant 100 MBit/s speed for indefinite long. The test 
have to be run on a simple HDD.

Test steps:
1. You have to use an XFS, EXT2 or ReiserFS partition for the test, Ext4 
forces flushes periodically. I recommend to use XFS.
2. create a big file on the test partiton. For 8 GByte RAM you can 
create a 2 GByte file. For 2 GB RAM I recommend to create 500MByte file. 
File creation can be done with this command:  dd if=/dev/zero 
of=bigfile2048M.bin bs=1M count=2048
3. compile pdflushtest.c: (gcc -o pdflushtest pdflushtest.c)
4. run pdflushtest: ./pdflushtest --file=/where/is/the/bigfile2048M.bin

In the beginning there can be some slowness even on well-working 
kernels. If you create the bigfile in the same run then it runs usually 
smootly from the beginning.

I don't know a setting of /proc/sys/vm variables which runs this test 
smootly on a 3.2.29 (3.0+) kernel. I think this is a kernel bug, because 
if I have much more "/proc/sys/vm/dirty_bytes" than the testfile size 
the test program should never be blocked.

A sample result:
11:20:05: speed:   99.994 MiB/s, time usage:  4.60 %, avg. block 
time:    1.8 us, max. block time: 18 us
11:20:06: speed:   99.994 MiB/s, time usage:  4.60 %, avg. block 
time:    1.8 us, max. block time: 10 us
11:20:07: speed:   99.994 MiB/s, time usage:  4.62 %, avg. block 
time:    1.8 us, max. block time: 11 us
11:20:08: speed:   99.989 MiB/s, time usage:  4.59 %, avg. block 
time:    1.8 us, max. block time: 58 us
11:20:09: speed:   99.997 MiB/s, time usage:  4.55 %, avg. block 
time:    1.8 us, max. block time: 13 us
11:20:10: speed:   28.840 MiB/s, time usage: 96.47 %, avg. block time:  
130.7 us, max. block time: 114076 us
11:20:11: speed:   30.505 MiB/s, time usage: 98.14 %, avg. block time:  
125.7 us, max. block time: 135008 us
11:20:12: speed:   25.956 MiB/s, time usage: 99.71 %, avg. block time:  
150.1 us, max. block time: 129839 us
11:20:13: speed:   25.088 MiB/s, time usage: 96.43 %, avg. block time:  
150.1 us, max. block time: 149649 us
11:20:14: speed:   32.438 MiB/s, time usage: 98.64 %, avg. block time:  
118.8 us, max. block time: 145649 us
11:20:15: speed:   22.765 MiB/s, time usage: 99.11 %, avg. block time:  
170.1 us, max. block time: 159749 us

At 11:20:10 the pdflush started its work, based on the 
"dirty_expire_centisecs". The test file was 2GByte, the 
/proc/sys/vm/dirty_bytes/dirty_bytes was 4000000000. The system (i5-3.4 
GHz, 8G RAM, Kernel 3.2.29-amd64) was booted to run this test only so it 
had 2,2 GByte RAM for cache, and 5.1 GByte RAM free (totally unused).

Sorry if I not found the right place to report this, please advise me 
were to send.

Best regards
Viktor Nagy

View attachment "pdflushtest.c" of type "text/x-csrc" (5799 bytes)

Powered by blists - more mailing lists