Re: [PATCHv4] mm: Fix calculation of dirtyable memory
From: Damien Wyart <hidden>
Date: 2012-11-17 20:41:54
Also in:
linux-mm, lkml
Attachments
- config.37 [application/octet-stream] 61674 bytes
From: Damien Wyart <hidden>
Date: 2012-11-17 20:41:54
Also in:
linux-mm, lkml
Hi,
Fix is to ensure we don't get an underflowed total of either highmem
or global dirtyable memory.
Signed-off-by: Sonny Rao <redacted>
Signed-off-by: Puneet Kumar <redacted>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
CC: stable@vger.kernel.org
---
v2: added apkm's suggestion to make the highmem calculation better
v3: added Fengguang Wu's suggestions fix zone_dirtyable_memory() and
(offlist mail) to use max() in global_dirtyable_memory()
v4: Added suggestions to description clarifying the role of highmem
and the commit which originally caused the problem
mm/page-writeback.c | 25 ++++++++++++++++++++-----
1 files changed, 20 insertions(+), 5 deletions(-)I am seeing a big performance regression with this patch applied on top of 3.7-rc6 : some actions generate a *lot* of disk activity (corresponding processes are shown in D state), and take a very long time to complete. The problem happens mainly when : - running apt-get update (this is a Debian system) : the last phase "reading packages lists" takes *minutes* with disk LED blinking, instead of a few seconds. - installing a kernel generated with kernel-package take also minutes on the "updating grub" step. I am attaching corresponding config. This is a 64-bit system with 6Go of memory and problems arise with memory not used a lot (several gigs of free memory). I guess this should be quite easy to reproduce... Thanks, Damien