linux-kernel - Re: [PATCH 2/2] [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] [day] [month] [year] [list]

Message-ID: <4F42D66D.8090604@linux.vnet.ibm.com>
Date:	Mon, 20 Feb 2012 15:25:33 -0800
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	NeilBrown <neilb@...e.de>
CC:	John Stultz <john.stultz@...aro.org>,
	Dave Chinner <david@...morbit.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Android Kernel Team <kernel-team@...roid.com>,
	Robert Love <rlove@...gle.com>, Mel Gorman <mel@....ul.ie>,
	Hugh Dickins <hughd@...gle.com>, Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILE
 flags

On 02/19/2012 11:34 PM, NeilBrown wrote:
> Is this a problem?  If the typical granularity is a page or two then it is
> unlikely to hurt.  If it is hundreds of pages I think it would mean that we
> don't make as good use of memory as we could (but it is all heuristics anyway
> and we probably waste lots of opportunities already so maybe it doesn't
> matter).
> 
> My gut feeling is that seeing the app has concrete knowledge about
> granularity it should give it to the kernel somehow.

I dunno...  The kernel works well with an awful lot of applications
without ever having any concept of the underlying objects.

I guess the worst-case scenario would be if we have a very large object,
most of its pages being accessed very often, but one never accessed.
The one page makes its way to the end of the LRU and gets discarded, now
the whole object is worthless, and most of it is at the beginning of the
LRU.  If it is truly accessed often, then userspace should notice
quickly and discard the entire object quickly.  If it isn't accessed
often, then the majority of the object is moving down the LRU and won't
be wasted for long.

What else can we do?  I guess whenever a range is set NONVOLATILE, we
could SetPageReferenced() on every page in the range to keep them
bunched up on the LRU.

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