On Fri 23-06-17 10:44:36, Alkis Georgopoulos wrote:

IGBPI?I1I? 23/06/2017 10:13 I?I 1/4 , I? Michal Hocko I-I3I?I+-I?Iu:

quoted

On Thu 22-06-17 12:37:36, Andrew Morton wrote:

What is your dirty limit configuration. Is your highmem dirtyable
(highmem_is_dirtyable)?

quoted

quoted

This issue happens on systems with any 4.x kernel, i386 arch, 16+ GB RAM.
It doesn't happen if we use 3.x kernels (i.e. it's a regression) or any 64bit
kernels (i.e. it only affects i386).

I remember we've had some changes in the way how the dirty memory is
throttled and 32b would be more sensitive to those changes. Anyway, I
would _strongly_ discourage you from using 32b kernels with that much of
memory. You are going to hit walls constantly and many of those issues
will be inherent. Some of them less so but rather non-trivial to fix
without regressing somewhere else. You can tune your system somehow but
this will be fragile no mater what.

Sorry to say that but 32b systems with tons of memory are far from
priority of most mm people. Just use 64b kernel. There are more pressing
problems to deal with.

Hi, I'm attaching below all my settings from /proc/sys/vm.

I think that the regression also affects 4 GB and 8 GB RAM i386 systems, but
not in an exponential manner; i.e. copies there are appear only 2-3 times
slower than they used to be in 3.x kernels.

If the regression shows with 4-8GB 32b systems then the priority for
fixing would be certainly much higher.

Now I don't know the kernel internals, but if disk copies show up to be 2-3
times slower, and the regression is in memory management, wouldn't that mean
that the memory management is *hundreds* of times slower, to show up in disk
writing benchmarks?

Well, it is hard to judge what the real problem is here but you have
to realize that 32b system has some fundamental issues which come from
how the memory has split between kernel (lowmem - 896MB at maximum) and
highmem. The more memory you have the more lowmem you consume by kernel
data structure. Just consider that ~160MB of this space is eaten by
struct pages to describe 16GB of memory. There are other data structures
which can only live in the low memory.

I.e. I'm afraid that this regression doesn't affect 16+ GB RAM systems only;
it just happens that it's clearly visible there.

And it might even affect 64bit systems with even more RAM; but I don't have
any such system to test with.

Not really. 64b systems do not need kernel/usespace split because the
address space large enough. If there are any regressions since 3.0 then
we are certainly interested in hearing about them.
 

root@pc:/proc/sys/vm# grep . *
dirty_ratio:20
highmem_is_dirtyable:0

this means that the highmem is not dirtyable and so only 20% of the free
lowmem (+ page cache in that region) is considered and writers might
get throttled quite early (this might be a really low number when the
lowmem is congested already). Do you see the same problem when enabling
highmem_is_dirtyable = 1?
-- 
Michal Hocko
SUSE Labs

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