Hi,

> Fix is to ensure we don't get an underflowed total of either highmem
> or global dirtyable memory.
>
> Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
> Signed-off-by: Puneet Kumar <puneetster@chromium.org>
> 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
[unhandled content-type:application/octet-stream]