linux-kernel - Re: [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and

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: <4ECC3DF8.4090902@redhat.com>
Date:	Tue, 22 Nov 2011 19:27:36 -0500
From:	Rik van Riel <riel@...hat.com>
To:	John Stultz <john.stultz@...aro.org>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Robert Love <rlove@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickins <hughd@...gle.com>, Mel Gorman <mel@....ul.ie>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Eric Anholt <eric@...olt.net>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Johannes Weiner <jweiner@...hat.com>,
	Jon Masters <jcm@...hat.com>
Subject: Re: [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE
 flags

On 11/22/2011 02:48 PM, John Stultz wrote:
> On Tue, 2011-11-22 at 04:37 -0500, Rik van Riel wrote:
>> On 11/21/2011 10:33 PM, John Stultz wrote:

> So similarly to Robert, I don't see this approach as necessarily
> exclusive to the volatile flags. There are just some tradeoffs with the
> different approaches.

Agreed, they might be complementary.

> The upside with your approach is that applications don't have to
> remember to re-pin the cache before using it and unpin it after its done
> using it.

If using these volatile regions is going to become
common, programs will be pinning and unpinning
those cache regions all the time, even when there
is no memory pressure at all.

At that point, I wonder if userspace programmers will
not end up making an automatic choice for a method
that does not impact their fast path at all, and only
gets invoked rarely.

> The downside is that the "please shrink your caches" message is likely
> to arrive when the system is low on resources. Once applications have
> been asked to "be nice and get small!", having to wait for that action
> to occur might not be great.

The pageout code in vmscan.c can send these messages
before we actually get around to evicting any anonymous
page from memory.

I believe the code we have there today can get these
signals sent before we get in any serious trouble.

> Where as with the volatile regions, there
> are just additionally easily freeable pages available when the kernel
> needs them.

That is certainly true.  However, it is unclear how
that would translate to virtualized solutions, since
there is no way for a virtual machine to mark pages
as volatile with the host (especially since there is
no way to tell the host what pages belong together
in objects).

I'm not objecting to your idea - in fact I like it.

However, I believe it would be good to answer some of
these questions before adding another interface to the
kernel that needs to be maintained forever.
--
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/