New: Old kernels copy memory faster than new

Bugme-new Andrew Morton 2 participants 2 messages Jul 24, 2008 – Jul 28, 2008 1 message not in the archive Memory management

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author maintainer

2008-07-24 19:26 UTC #1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 41 lines · On Thu, 24 Jul 2008 10:57:42 -0700 (PDT) [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=11156
Summary: Old kernels copy memory faster than new
Product: IO/Storage
Version: 2.5
KernelVersion: 2.6.24, 2.6.25
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Block Layer
AssignedTo: [email protected]
ReportedBy: [email protected]
Latest working kernel version: 2.6.25 Earliest failing kernel version: 2.6.24
Distribution: Slackware 10-12
First machine:
CPU - AMD Athlon3600+(2______) Chipset - nForce 6150(MCP51) RAM - 3G DDR2
Video - internal GeForce6150 Kernel - 2.6.25.4(own built) Copy speed - 1.7GByte/s
on another kernel:
Kernel - 2.6.23.5(own built)
Copy speed - 43.5GByte/s
--------------------------------------------
Second machine:
CPU - PII-350
MB i440BX
RAM - 128M SDRAM
Video - 3DFX Voodoo3
Kernel - 2.6.21.5(Vanila from slackware distribution) Copy speed - 11.3GByte/s

Quoted 3 lines

Steps to reproduce:
dd if=/dev/zero of=/dev/null bs=16M count=10000

lol. OK, who did that?

Perhaps ZERO_PAGE changes?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hugh Dickins

2008-07-28 17:13 UTC #2 lore raw

Quoted 8 lines · Andrew Morton

Quoted 8 lines
http://bugzilla.kernel.org/show_bug.cgi?id=11156
Kernel - 2.6.25.4(own built)
Copy speed - 1.7GByte/s
Kernel - 2.6.23.5(own built)
Copy speed - 43.5GByte/s

Quoted 6 lines

Quoted 2 lines
Steps to reproduce:
dd if=/dev/zero of=/dev/null bs=16M count=10000
lol. OK, who did that?
Perhaps ZERO_PAGE changes?

Yes, the ZERO_PAGE changes: readprofile clearly shows lots of time in clear_user() on 2.6.24 onwards, clearing each page instead of using the ZERO_PAGE.

I see Nick has already answered this, and the bug is now closed (guess he's on 2.6.23 whereas I'm on later ;). I agree with him, copying from /dev/zero to /dev/null is not an operation which deserves VM tricks to optimize; but I wanted to add one point.

The particular awfulness of those dd rates (on machines I've tried I see new kernels as 10 to 30 times worse than old kernels at that test) owes a lot to the large blocksize (16M) being used.

That blocksize will not fit in the processor's memory cache, so repeatedly clearing the pages is very slow. Bring the blocksize down to something that easily fits in the L2 cache, perhaps 1M or 256k, and new kernels then appear only twice(ish) as bad as old.

Nothing to be proud of, but not nearly so bad as the bs=16M case.

Hugh