linux-kernel - Re: File copy is very slow on linux-3.4.2 (or linux-3.3x) on a specific hardware: AMD FX-8150 + 990FX

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: <4FD7C595.202@free.fr>
Date:	Wed, 13 Jun 2012 00:41:25 +0200
From:	Wallak <wallak@...e.fr>
To:	Jan Kara <jack@...e.cz>
CC:	linux-kernel@...r.kernel.org
Subject: Re: File copy is very slow on linux-3.4.2 (or linux-3.3x) on a specific
 hardware: AMD FX-8150 + 990FX

Jan Kara wrote:
> On Tue 12-06-12 20:39:32, Wallak wrote:
>> Jan Kara wrote:
>>> On Mon 11-06-12 21:54:16, wallak@...e.fr wrote:
>>>> I've a very annoying issue on recent kernel (linux-3.4.2-SMP) with my main motherboard (AMD FX-8150 + 990FX - 8 cores 4.1GHz), file copy is very slow (see below). The same kernel works flawlessly on an AMD E450 2 cores motherboard.
>>>>
>>>> Linux-3.2.20 works properly on this hardware.
>>>> hdparm -t gives good results on both kernels.
>>>>
>>>> I've no idea where this bug come from. Do you have this issue on your hardware ? A patch is available ?
>>>>
>>>>
>>>> *linux-3.4.2
>>>> dd if=../in/file_8gb.tmp of=tmp.tmp bs=1024k count=100
>>>> 100+0 records in
>>>> 100+0 records out
>>>> 104857600 bytes (105 MB) copied, 132.884 s, 789 kB/s
>>>>
>>>>
>>>> *linux-3.2.20
>>>> dd if=../in/file_8gb.tmp of=tmp.tmp bs=1024k count=100
>>>> 100+0 records in
>>>> 100+0 records out
>>>> 104857600 bytes (105 MB) copied, 3.30793 s, 31.7 MB/s
>>>    So let's separate reading and writing part first. What is the speed of
>>> dd if=../in/file_8gb.tmp of=/dev/null bs=1M count=100
>>>    on both kernels?
>>> And what is the speed of:
>>> dd if=/dev/zero of=tmp.tm bs=1M count=100
>> You're right, the issue is only while writing. The results are below:
>>
>> #linux-3.4.2
>> dd if=/dev/zero of=tmp.tm bs=1M count=100
>> 100+0 records in
>> 100+0 records out
>> 104857600 bytes (105 MB) copied, 151.347 s, 693 kB/s
>> dd if=../in/file_8gb.tmp of=/dev/null bs=1M count=100
>> 100+0 records in
>> 100+0 records out
>> 104857600 bytes (105 MB) copied, 1.26228 s, 83.1 MB/s
>>
>> #linux-3.2.20
>> dd if=/dev/zero of=tmp.tm bs=1M count=100
>> 100+0 records in
>> 100+0 records out
>> 104857600 bytes (105 MB) copied, 1.00838 s, 104 MB/s
>> dd if=../in/file_8gb.tmp of=/dev/null bs=1M count=100
>> 100+0 records in
>> 100+0 records out
>> 104857600 bytes (105 MB) copied, 1.26947 s, 82.6 MB/s
>>
>>
>>>    Also what filesystems are you using?
>> This is an ext2 file system:
>>
>> /dev/sda6      ext2    464463364 323380956 141082408  70% /backup
>    OK, I'm surprised by one thing - how come the writes do no end up cached
> in memory (thus you should get much higher throughput). Is the filesystem
> mounted with -o sync option by any chance?
>
> 								Honza

     I've tried with an nfs mounted drive, the issue is still there, it 
seems to be global. With sync enabled, the output is quite faster, 
that's quite unexpected.
On my AMD E450 motherboard this kernel works fine - Are you able to 
reproduce this behavior ?


#/dev/sda6 /backup ext2 rw,relatime,errors=continue 0 0           
(/proc/mount)
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 155.407 s, 675 kB/s

#/dev/sda6 /backup ext2 rw,sync,relatime,errors=continue 0 0
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 69.7868 s, 1.5 MB/s

#nfs drive - same issue:
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 221.572 s, 473 kB/s

Best Regards,
Wallak.


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