Re: [PATCH][RF C/T/D] Unmapped page cache control - via boot parameter

From: Avi Kivity
Date: Mon Mar 15 2010 - 04:28:15 EST


On 03/15/2010 10:07 AM, Balbir Singh wrote:
* Avi Kivity<avi@xxxxxxxxxx> [2010-03-15 09:48:05]:

On 03/15/2010 09:22 AM, Balbir Singh wrote:
Selectively control Unmapped Page Cache (nospam version)

From: Balbir Singh<balbir@xxxxxxxxxxxxxxxxxx>

This patch implements unmapped page cache control via preferred
page cache reclaim. The current patch hooks into kswapd and reclaims
page cache if the user has requested for unmapped page control.
This is useful in the following scenario

- In a virtualized environment with cache!=none, we see
double caching - (one in the host and one in the guest). As
we try to scale guests, cache usage across the system grows.
The goal of this patch is to reclaim page cache when Linux is running
as a guest and get the host to hold the page cache and manage it.
There might be temporary duplication, but in the long run, memory
in the guests would be used for mapped pages.
Well, for a guest, host page cache is a lot slower than guest page cache.

Yes, it is a virtio call away, but is the cost of paying twice in
terms of memory acceptable?

Usually, it isn't, which is why I recommend cache=off.

One of the reasons I created a boot
parameter was to deal with selective enablement for cases where
memory is the most important resource being managed.

I do see a hit in performance with my results (please see the data
below), but the savings are quite large. The other solution mentioned
in the TODOs is to have the balloon driver invoke this path. The
sysctl also allows the guest to tune the amount of unmapped page cache
if needed.

The knobs are for

1. Selective enablement
2. Selective control of the % of unmapped pages

An alternative path is to enable KSM for page cache. Then we have direct read-only guest access to host page cache, without any guest modifications required. That will be pretty difficult to achieve though - will need a readonly bit in the page cache radix tree, and teach all paths to honour it.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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