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

Message-ID: <1329450573.2373.11.camel@js-netbook>
Date:	Thu, 16 Feb 2012 19:49:33 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Dmitry Adamushko <dmitry.adamushko@...il.com>
Cc:	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>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 2/2] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and
 _NONVOLATILE flags

On Sun, 2012-02-12 at 15:08 +0100, Dmitry Adamushko wrote:
> On 10 February 2012 01:16, John Stultz <john.stultz@...aro.org> wrote:
> Also, I have a question about mapping_range_volatile().
[snip]
> +       new->mapping = mapping;
> +       new->range_node.start = start;
> +       new->range_node.end = end;
> +       new->purged = purged;
> 
> I'm wondering whether this 'inheritance' is always desirable.
> 
> Say,
> 
> mapping_range_volatile(mapping, X, X + 1);
> ...
> time goes by and volatile_shrink() has been called for this region.
> 
> now, a user does the following (is it considered bad user-behavior?)
> 
> mapping_range_volatile(mapping, Y = X - big_value, Z = X + big_value);
> 
> This new range will 'inherit' purged=1 from the old one and won't be
> on the lru_list. Yet, it's much bigger than the old one and so many
> pages are not really 'volatile'.

Yea, I think this is a interesting point, and we can probably be a
little smarter then what is done here. We could only coalesce ranges
that haven't been purged, for instance. Although, the coalescing of
neighboring ranges in of itself is sort of questionable, as if they were
marked volatile independently, they may be marked nonvolatile
independently as well, so merging them together mucks up the lru
ordering.

Robert/Brian: Is there strong rational for the coalescing of neighboring
ranges in ashmem?

thanks
-john


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