Message-ID: <CAG6tG3y+C4815b=bByU7ZeOVE9o1g71QoSpRRUud5jcDFqK_Ow@mail.gmail.com>
Date:	Tue, 22 Nov 2011 11:31:32 -0500
From:	Robert Love <rlove@...gle.com>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [RFC] fadvise: Add _VOLATILE,_ISVOLATILE, and
 _NONVOLATILE flags

First, thanks to John for driving this. I'd love to see something like
ashmem's cache functionality in Linux.

Comments inline:

On Tue, Nov 22, 2011 at 4:37 AM, Rik van Riel <riel@...hat.com> wrote:
> 1) How do you tell userspace some of its data got
>   discarded?

This is my big question, too. This must be addressed to make this
usable by user-space. Unfortunately there isn't a side channel
available in madvise or fadvise.

The ashmem use case is like this:

1. Create an ashmem mapping. All pages start off pinned.
2. Populate pages
3. Use pages.
4. Unpin some or all pages.
5. Re-pin pages. Return value tells you if they were jettisoned. If
so, goto #2. If not, goto #3.

> 2) How do you prevent the situation where every
>   volatile object gets a few pages discarded, making
>   them all unusable?
>   (better to throw away an entire object at once)

In ashmem, I prevent this by jettisoning pages in units of unpinned
chunks, ordered by least-recently-unpinned. Since pinned/unpinned
chunks tend to relate to user-space objects (e.g. you'd unpin a whole
image), you end up throwing away the entire user-space object.

Put another way, the eviction algorithm is least-recently-unpinned
chunk, not least-recently-unpinned page, which prevents thrashing lots
of objects. An alternative would be to toss not whole chunks, but
whole mappings.

> 3) Isn't it too slow for something like Firefox to
>   create a new tmpfs object for every single throw-away
>   cache object?

Nope, although user-space might want to create larger mappings and
sub-divide them if its objects are *really* small.

> Johannes, Jon and I have looked at an alternative way to
> allow the kernel and userspace to cooperate in throwing
> out cached data.  This alternative way does not touch
> the alloc/free fast path at all, but does require some
> cooperation at "shrink cache" time.

I'm open to whatever works, and I need to think about your proposal
more, but it sounds inferior to the model John is proposing.

I think we can sum the two models up as,

- User-space pins, unpins objects, and kernel handles eviction
- Kernel lets user-space register callbacks for notification during
cache shrink, user handles eviction

Right?

Actually, I can see the need for both. But the first is simpler, lets
the kernel evict pages from user-space even in low memory situations
(since you can call the cache shrinker atomically), and relies on the
fact that the "free caches" action is just jettisoning the pages, so
the kernel can do it. The actual work is in repopulating the caches.

That last point, btw, is why user-space developers like ashmem: It
fits their models of how they do work. They pin/unpin objects as part
of their normal access and repopulating is tied into the re-pin path,
which is where it makes sense.

In a callback model, you have two issues: One, user-space needs to do
its own jettisoning. Two, user-space now needs to keep track of
whether an object was jettisoned and repopulate it (when? on next use?
now you have user-space reimplementing the pin/unpin logic, right?).

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

Powered by blists - more mailing lists