Thread (6 messages) 6 messages, 4 authors, 2012-11-19

Re: [PATCHv4] mm: Fix calculation of dirtyable memory

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

Attachments

  • config.37 [application/octet-stream] 61674 bytes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help