linux-kernel - Re: [PATCH v3 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20150720175538.GJ2561@suse.de>
Date:	Mon, 20 Jul 2015 18:55:38 +0100
From:	Mel Gorman <mgorman@...e.de>
To:	PINTU KUMAR <pintu.k@...sung.com>
Cc:	akpm@...ux-foundation.org, corbet@....net, vbabka@...e.cz,
	gorcunov@...nvz.org, mhocko@...e.cz, emunson@...mai.com,
	kirill.shutemov@...ux.intel.com, standby24x7@...il.com,
	hannes@...xchg.org, vdavydov@...allels.com, hughd@...gle.com,
	minchan@...nel.org, tj@...nel.org, rientjes@...gle.com,
	xypron.glpk@....de, dzickus@...hat.com, prarit@...hat.com,
	ebiederm@...ssion.com, rostedt@...dmis.org, uobergfe@...hat.com,
	paulmck@...ux.vnet.ibm.com, iamjoonsoo.kim@....com,
	ddstreet@...e.org, sasha.levin@...cle.com, koct9i@...il.com,
	cj@...ux.com, opensource.ganesh@...il.com, vinmenon@...eaurora.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, linux-pm@...r.kernel.org, qiuxishi@...wei.com,
	Valdis.Kletnieks@...edu, cpgs@...sung.com, pintu_agarwal@...oo.com,
	vishnu.ps@...sung.com, rohit.kr@...sung.com, iqbal.ams@...sung.com,
	pintu.ping@...il.com, pintu.k@...look.com
Subject: Re: [PATCH v3 1/1] kernel/sysctl.c: Add /proc/sys/vm/shrink_memory
 feature

On Mon, Jul 20, 2015 at 09:43:02PM +0530, PINTU KUMAR wrote:
> Hi,
> 
> Thank you all for reviewing the patch and providing your valuable comments and
> suggestions.
> During the ELC conference many people suggested to release the patch to
> mainline, so this patch, to get others opinion.
> 

Unfortunately, in my opinion it runs the risk of creating a different
set of problems. Either it needs to be run frequently to keep memory free
which incurs one set of penalties or it is used too late when there are
unmovable/unreclaimable pages preventing allocations succeeding in which
case you are back at the original problem. I see what you did and why it
would work in some cases but I think the main reason it works is because
it's run frequently enough so memory is never used. Grouping pages by
mobility actually took advantage of a similar property when it increased
min_free_kbytes but that was much more limited than adding a giant hammer
for userspace to reclaim the world.

> If you have any more suggestions to experiment and verify please let me know.
> 

I believe I already did. If it's high-order reliability that is important
then you need to either reserve the memory or look at protecting the pages
using grouping pages by mobility. I pointed out what series to look at and
the leader explains how it could be adjusted further for the embedded case
if necessary.

If it's latency you are interested in then reclaim/compaction needs to
be modified to be more aggressive when it is somehow detected that the
high-order allocation must succeed for functional correctness. In that case
the relational starting point would be to look at should_continue_reclaim
and how it relates to compaction.

> The suggestion was only to open up the shrink_all_memory API for some use cases.
> 
> I am not saying that it needs to be called continuously. It can be used only on
> certain condition and only when deemed necessary.
> The same technique is already used in hibernation to reduce the RAM snapshot
> image size.

Reducing memory usage is not the same as guaranteeing that high-order
pages are available for allocation.

-- 
Mel Gorman
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/