linux-kernel - Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches

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: <alpine.LRH.2.00.1602152258240.4623@mcp-bld-lnx-277.cisco.com>
Date:	Mon, 15 Feb 2016 23:14:13 -0800 (PST)
From:	Nag Avadhanam <nag@...co.com>
To:	Dave Chinner <david@...morbit.com>
cc:	"Theodore Ts'o" <tytso@....edu>,
	"Daniel Walker (danielwa)" <danielwa@...co.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	"Khalid Mughal (khalidm)" <khalidm@...co.com>,
	"xe-kernel@...ernal.cisco.com" <xe-kernel@...ernal.cisco.com>,
	"dave.hansen@...el.com" <dave.hansen@...el.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>,
	"riel@...hat.com" <riel@...hat.com>,
	Jonathan Corbet <corbet@....net>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count

On Mon, 15 Feb 2016, Dave Chinner wrote:

> On Tue, Feb 16, 2016 at 02:58:04AM +0000, Nag Avadhanam (nag) wrote:
>> Its the calculation of the # of bytes of non-reclaimable file system cache
>> pages that has been troubling us. We do not want to count inactive file
>> pages (of programs/binaries) that were once mapped by any process in the
>> system as reclaimable because that might lead to thrashing under memory
>> pressure (we want to alert admins before system starts dropping text
>> pages).
>
> The code presented does not match your requirements. It only counts
> pages that are currently mapped into ptes. hence it will tell you
> that once-used and now unmapped binary pages are reclaimable, and
> drop caches will reclaim them. hence they'll need to be fetched from
> disk again if they are faulted in again after a drop_caches run.

Will the inactive binary pages be automatically unmapped even if the process
into whose address space they are mapped is still around? I thought they
are left mapped until such time there is memory pressure.

We only care for binary pages (active and inactive) mapped into the address 
spaces of live processes. Its okay to aggressively reclaim inactive
pages once mapped into processes that are no longer around.

thanks,
nag

>
> Cheers,
>
> Dave.
> -- 
> Dave Chinner
> david@...morbit.com
>