linux-kernel - Re: [PATCH 0/8] mm: add page cache limit and reclaim feature

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] [day] [month] [year] [list]

Message-ID: <20140624073659.GA15337@dhcp22.suse.cz>
Date:	Tue, 24 Jun 2014 09:36:59 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Xishi Qiu <qiuxishi@...wei.com>
Cc:	Rafael Aquini <aquini@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Rik van Riel <riel@...hat.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Linux MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizefan@...wei.com>
Subject: Re: [PATCH 0/8] mm: add page cache limit and reclaim feature

On Tue 24-06-14 10:25:32, Xishi Qiu wrote:
> On 2014/6/23 19:29, Michal Hocko wrote:
[...]
> > This doesn't make much sense to me. So you have a problem with latency
> > caused by direct reclaim so you add a new way of direct page cache
> > reclaim.
> > 
> >> A user process produces page cache frequently, so free memory is not
> >> enough after running a long time. Slow path takes much more time because 
> >> direct reclaim. And kswapd will reclaim memory too, but not much. Thus it
> >> always triggers slow path. this will cause performance regression.
> > 
> > If I were you I would focus on why the reclaim doesn't catch up with the
> > page cache users. The mechanism you are proposing in unacceptable.
> 
> Hi Michal,
> 
> Do you mean why the reclaim is slower than page cache increase?
> 
> I think there are two reasons:
> 1. kswapd and direct_reclaim will be triggered only when there is not 
> enough memory(e.g. __alloc_pages_slowpath()). That means it will not 
> reclaim when memory is enough(e.g. get_page_from_freelist()).

Yeah and that is the whole point. If you want to start to reclaim earlier
because you need a bigger pillow for the free memory for sudden memory
pressure then increase min_free_kbytes.

> 2. __alloc_pages_direct_reclaim
> 	try_to_free_pages
> 		nr_to_reclaim = SWAP_CLUSTER_MAX
> And "#define SWAP_CLUSTER_MAX 32UL", that means it expect to reclaim 32
> pages. It is too few, if we alloc 2^10 pages in one time.

Maybe _userspace_ allocates that much of memory but it is not faulted
in/allocated by kernel in one shot. Besides that at the time you enter
direct reclaim kswapd should be reclaiming memory to balance zones.
So reclaiming SWAP_CLUSTER_MAX from the direct reclaim shouldn't
matter that much. If it does then show us some numbers to prove it.
SWAP_CLUSTER_MAX is kind of arbitrary number but I haven't seen any
reclaim regression becuse of this value being too small AFAIR.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/