Re: IO regression after ab8fabd46f on x86 kernels with high memory

From: Rik van Riel
Date: Fri Apr 26 2013 - 21:54:16 EST

On 04/26/2013 07:44 PM, Pierre-Loup A. Griffais wrote:
I initially observed this between kernels 3.2 and 3.5: on 3.2, copying a
180M shared object on the same ext4 filesystem takes 0.6s. On 3.5, it
takes between two and three minutes. It looks like a similar throughput
regression happens on any machine running an i386 PAE kernel with high
amounts of memory; the threshold seems to be 16G; passing mem=15G to the
kernel commandline fixes it.

If you have that much memory in the system, you will
want to run a 64 bit kernel to avoid all kinds of
memory management corner cases.

I bisected it to the following change:

commit ab8fabd46f811d5153d8a0cd2fac9a0d41fb593d
Author: Johannes Weiner <jweiner@xxxxxxxxxx>
Date: Tue Jan 10 15:07:42 2012 -0800

mm: exclude reserved pages from dirtyable memory

I realize running x86 kernels against high amounts of memory is not
advised for various reasons, but I would assume that such a big
regression in basic functionality to not be part of them. Is that
accurate, or are these configurations expected to become unusable from
3.3 onwards?

Reverting that patch would probably break i686 PAE systems with
lots of memory at a different threshold.

With more than 8-12GB of memory, an i686 kernel is between a
rock and a hard place. Whether you move it closer to the rock,
or closer to the hard place, all you do is change the way in
which it breaks.

Also CCing Sonny since it looks like he tried to fix an overflow issue
related to the same change with commit c8b74c2f66049, but I'm still
experiencing the problem with a kernel built from master.

- Pierre-Loup

All rights reversed
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at