Re: [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and _NONVOLATILEflags

[Rik van Riel]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/