linux-kernel - Re: [PATCHv4] mm: Fix calculation of dirtyable memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Nov 2012 21:41:51 +0100
From:	Damien Wyart <damien.wyart@...il.com>
To:	Sonny Rao <sonnyrao@...omium.org>
Cc:	linux-kernel@...r.kernel.org,
	Fengguang Wu <fengguang.wu@...el.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
	Mandeep Singh Baines <msb@...omium.org>,
	Johannes Weiner <jweiner@...hat.com>,
	Olof Johansson <olofj@...omium.org>,
	Will Drewry <wad@...omium.org>,
	Kees Cook <keescook@...omium.org>,
	Aaron Durbin <adurbin@...omium.org>, stable@...r.kernel.org,
	Puneet Kumar <puneetster@...omium.org>
Subject: Re: [PATCHv4] mm: Fix calculation of dirtyable memory

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@...omium.org>
> Signed-off-by: Puneet Kumar <puneetster@...omium.org>
> Acked-by: Johannes Weiner <hannes@...xchg.org>
> CC: stable@...r.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

Download attachment "config.37" of type "application/octet-stream" (61674 bytes)