KVM page cache optimization (v2)

Selectively control Unmapped Page Cache (nospam version)

From: Balbir Singh <[email protected]>

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=writethrough, 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.
- The option is controlled via a boot option and the administrator can selectively turn it on, on a need to use basis.

A lot of the code is borrowed from zone_reclaim_mode logic for __zone_reclaim(). One might argue that the with ballooning and KSM this feature is not very useful, but even with ballooning, we need extra logic to balloon multiple VM machines and it is hard to figure out the correct amount of memory to balloon. With these patches applied, each guest has a sufficient amount of free memory available, that can be easily seen and reclaimed by the balloon driver. The additional memory in the guest can be reused for additional applications or used to start additional guests/balance memory in the host.

KSM currently does not de-duplicate host and guest page cache. The goal of this patch is to help automatically balance unmapped page cache when instructed to do so.

There are some magic numbers in use in the code, UNMAPPED_PAGE_RATIO and the number of pages to reclaim when unmapped_page_control argument is supplied. These numbers were chosen to avoid aggressiveness in reaping page cache ever so frequently, at the same time providing control.

The sysctl for min_unmapped_ratio provides further control from within the guest on the amount of unmapped pages to reclaim.

Quoted 39 lines · Balbir Singh

Selectively control Unmapped Page Cache (nospam version)

From: Balbir Singh <[email protected]>

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=writethrough, 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.
- The option is controlled via a boot option and the administrator can selectively turn it on, on a need to use basis.

A lot of the code is borrowed from zone_reclaim_mode logic for __zone_reclaim(). One might argue that the with ballooning and KSM this feature is not very useful, but even with ballooning, we need extra logic to balloon multiple VM machines and it is hard to figure out the correct amount of memory to balloon. With these patches applied, each guest has a sufficient amount of free memory available, that can be easily seen and reclaimed by the balloon driver. The additional memory in the guest can be reused for additional applications or used to start additional guests/balance memory in the host.

KSM currently does not de-duplicate host and guest page cache. The goal of this patch is to help automatically balance unmapped page cache when instructed to do so.

There are some magic numbers in use in the code, UNMAPPED_PAGE_RATIO and the number of pages to reclaim when unmapped_page_control argument is supplied. These numbers were chosen to avoid aggressiveness in reaping page cache ever so frequently, at the same time providing control.

Quoted 3 lines

The sysctl for min_unmapped_ratio provides further control from within the guest on the amount of unmapped pages to reclaim.

Are there any major objections to this patch?

Quoted 45 lines · On Mon, 14 Jun 2010 00:01:45 +0530 Balbir Singh <[email protected]>…

Quoted 42 lines · Balbir Singh

Selectively control Unmapped Page Cache (nospam version)

From: Balbir Singh <[email protected]>

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=writethrough, 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.
- The option is controlled via a boot option and the administrator can selectively turn it on, on a need to use basis.

A lot of the code is borrowed from zone_reclaim_mode logic for __zone_reclaim(). One might argue that the with ballooning and KSM this feature is not very useful, but even with ballooning, we need extra logic to balloon multiple VM machines and it is hard to figure out the correct amount of memory to balloon. With these patches applied, each guest has a sufficient amount of free memory available, that can be easily seen and reclaimed by the balloon driver. The additional memory in the guest can be reused for additional applications or used to start additional guests/balance memory in the host.

KSM currently does not de-duplicate host and guest page cache. The goal of this patch is to help automatically balance unmapped page cache when instructed to do so.

There are some magic numbers in use in the code, UNMAPPED_PAGE_RATIO and the number of pages to reclaim when unmapped_page_control argument is supplied. These numbers were chosen to avoid aggressiveness in reaping page cache ever so frequently, at the same time providing control.

The sysctl for min_unmapped_ratio provides further control from within the guest on the amount of unmapped pages to reclaim.

Quoted 2 lines

Are there any major objections to this patch?

This kind of patch needs "how it works well" measurement.

- How did you measure the effect of the patch ? kernbench is not enough, of course.

- Why don't you believe LRU ? And if LRU doesn't work well, should it be fixed by a knob rather than generic approach ?
- No side effects ?

- Linux vm guys tend to say, "free memory is bad memory". ok, for what free memory created by your patch is used ? IOW, I can't see the benefit. If free memory that your patch created will be used for another page-cache, it will be dropped soon by your patch itself.

If your patch just drops "duplicated, but no more necessary for other kvm", I agree your patch may increase available size of page-caches. But you just drops unmapped pages.

Quoted 3 lines

- Why don't you believe LRU ? And if LRU doesn't work well, should it be fixed by a knob rather than generic approach ?
- No side effects ?

I believe in LRU, just that the problem I am trying to solve is of using double the memory for caching the same data (consider kvm running in cache=writethrough or writeback mode, both the hypervisor and the guest OS maintain a page cache of the same data). As the VM's grow the overhead is substantial. In my runs I found upto 60% duplication in some cases.

- Linux vm guys tend to say, "free memory is bad memory". ok, for what free memory created by your patch is used ? IOW, I can't see the benefit. If free memory that your patch created will be used for another page-cache, it will be dropped soon by your patch itself.

Free memory is good for cases when you want to do more in the same system. I agree that in a bare metail environment that might be partially true. I don't have a problem with frequently used data being cached, but I am targetting a consolidated environment at the moment. Moreover, the administrator has control via a boot option, so it is non-instrusive in many ways.

From performance perspective, I don't see any advantage to drop caches

Quoted 17 lines · On Mon, 14 Jun 2010 12:19:55 +0530 Balbir Singh <[email protected]>…

Quoted 3 lines

- Why don't you believe LRU ? And if LRU doesn't work well, should it be fixed by a knob rather than generic approach ?
- No side effects ?

I believe in LRU, just that the problem I am trying to solve is of using double the memory for caching the same data (consider kvm running in cache=writethrough or writeback mode, both the hypervisor and the guest OS maintain a page cache of the same data). As the VM's grow the overhead is substantial. In my runs I found upto 60% duplication in some cases.

- Linux vm guys tend to say, "free memory is bad memory". ok, for what free memory created by your patch is used ? IOW, I can't see the benefit. If free memory that your patch created will be used for another page-cache, it will be dropped soon by your patch itself.

Quoted 6 lines

Free memory is good for cases when you want to do more in the same system. I agree that in a bare metail environment that might be partially true. I don't have a problem with frequently used data being cached, but I am targetting a consolidated environment at the moment. Moreover, the administrator has control via a boot option, so it is non-instrusive in many ways.

It sounds that what you want is to improve performance etc. but to make it easy sizing the system and to help admins. Right ?

From performance perspective, I don't see any advantage to drop caches which can be dropped easily. I just use cpus for the purpose it may no be necessary.

Quoted 3 lines

It sounds that what you want is to improve performance etc. but to make it easy sizing the system and to help admins. Right ?

Right, to allow freeing up of using double the memory to cache data.

Balloon unmapped page cache pages first

From: Balbir Singh<[email protected]>

This patch builds on the ballooning infrastructure by ballooning unmapped page cache pages first. It looks for low hanging fruit first and tries to reclaim clean unmapped pages first.

The key advantage was that it resulted in lesser RSS usage in the host and more cached usage, indicating that the caching had been pushed towards the host. The guest cached memory usage was lower and free memory in the guest was also higher.

Quoted 7 lines · Balbir Singh

Balloon unmapped page cache pages first

From: Balbir Singh<[email protected]>

This patch builds on the ballooning infrastructure by ballooning unmapped page cache pages first. It looks for low hanging fruit first and tries to reclaim clean unmapped pages first.

I'm not sure victimizing unmapped cache pages is a good idea. Shouldn't page selection use the LRU for recency information instead of the cost of guest reclaim? Dropping a frequently used unmapped cache page can be more expensive than dropping an unused text page that was loaded as part of some executable's initialization and forgotten.

Many workloads have many unmapped cache pages, for example static web serving and the all-important kernel build.

Quoted 4 lines

The key advantage was that it resulted in lesser RSS usage in the host and more cached usage, indicating that the caching had been pushed towards the host. The guest cached memory usage was lower and free memory in the guest was also higher.

Caching in the host is only helpful if the cache can be shared, otherwise it's better to cache in the guest.

Quoted 6 lines

I'm not sure victimizing unmapped cache pages is a good idea. Shouldn't page selection use the LRU for recency information instead of the cost of guest reclaim? Dropping a frequently used unmapped cache page can be more expensive than dropping an unused text page that was loaded as part of some executable's initialization and forgotten.

We victimize the unmapped cache only if it is unused (in LRU order). We don't force the issue too much. We also have free slab cache to go after.

Quoted 7 lines · Balbir Singh

Quoted 6 lines

I'm not sure victimizing unmapped cache pages is a good idea. Shouldn't page selection use the LRU for recency information instead of the cost of guest reclaim? Dropping a frequently used unmapped cache page can be more expensive than dropping an unused text page that was loaded as part of some executable's initialization and forgotten.

Quoted 3 lines

We victimize the unmapped cache only if it is unused (in LRU order). We don't force the issue too much. We also have free slab cache to go after.

Just to be clear, let's say we have a mapped page (say of /sbin/init) that's been unreferenced since _just_ after the system booted. We also have an unmapped page cache page of a file often used at runtime, say one from /etc/resolv.conf or /etc/passwd.

Quoted 8 lines · On Thu, 10 Jun 2010 17:07:32 -0700 Dave Hansen <[email protected]> wrote:

Quoted 7 lines · Balbir Singh

Quoted 6 lines

I'm not sure victimizing unmapped cache pages is a good idea. Shouldn't page selection use the LRU for recency information instead of the cost of guest reclaim? Dropping a frequently used unmapped cache page can be more expensive than dropping an unused text page that was loaded as part of some executable's initialization and forgotten.

Quoted 9 lines

Quoted 3 lines

We victimize the unmapped cache only if it is unused (in LRU order). We don't force the issue too much. We also have free slab cache to go after.

Just to be clear, let's say we have a mapped page (say of /sbin/init) that's been unreferenced since _just_ after the system booted. We also have an unmapped page cache page of a file often used at runtime, say one from /etc/resolv.conf or /etc/passwd.

Hmm. I'm not fan of estimating working set size by calculation based on some numbers without considering history or feedback.

Can't we use some kind of feedback algorithm as hi-low-watermark, random walk or GA (or somehing more smart) to detect the size ?

Quoted 24 lines · KAMEZAWA Hiroyuki

Quoted 8 lines · On Thu, 10 Jun 2010 17:07:32 -0700 Dave Hansen <[email protected]> wrote:

Quoted 7 lines · Balbir Singh

Quoted 6 lines

I'm not sure victimizing unmapped cache pages is a good idea. Shouldn't page selection use the LRU for recency information instead of the cost of guest reclaim? Dropping a frequently used unmapped cache page can be more expensive than dropping an unused text page that was loaded as part of some executable's initialization and forgotten.

Quoted 9 lines

Quoted 3 lines

We victimize the unmapped cache only if it is unused (in LRU order). We don't force the issue too much. We also have free slab cache to go after.

Just to be clear, let's say we have a mapped page (say of /sbin/init) that's been unreferenced since _just_ after the system booted. We also have an unmapped page cache page of a file often used at runtime, say one from /etc/resolv.conf or /etc/passwd.

Hmm. I'm not fan of estimating working set size by calculation based on some numbers without considering history or feedback.

Quoted 3 lines

Can't we use some kind of feedback algorithm as hi-low-watermark, random walk or GA (or somehing more smart) to detect the size ?

Could you please clarify at what level you are suggesting size detection? I assume it is outside the OS, right?

I can think of both way in kernel and in user approarh and they should be complement to each other.

An example of kernel-based approach is.
1. add a shrinker callback(A) for balloon-driver-for-guest as guest kswapd.
2. add a shrinker callback(B) for balloon-driver-for-host as host kswapd.
(I guess current balloon driver is only for host. Please imagine.)

Quoted 26 lines · On Fri, 11 Jun 2010 10:16:32 +0530 Balbir Singh <[email protected]>…

Quoted 24 lines · KAMEZAWA Hiroyuki

Quoted 8 lines · On Thu, 10 Jun 2010 17:07:32 -0700 Dave Hansen <[email protected]> wrote:

Quoted 7 lines · Balbir Singh

Quoted 6 lines

I'm not sure victimizing unmapped cache pages is a good idea. Shouldn't page selection use the LRU for recency information instead of the cost of guest reclaim? Dropping a frequently used unmapped cache page can be more expensive than dropping an unused text page that was loaded as part of some executable's initialization and forgotten.

Quoted 9 lines

Quoted 3 lines

We victimize the unmapped cache only if it is unused (in LRU order). We don't force the issue too much. We also have free slab cache to go after.

Just to be clear, let's say we have a mapped page (say of /sbin/init) that's been unreferenced since _just_ after the system booted. We also have an unmapped page cache page of a file often used at runtime, say one from /etc/resolv.conf or /etc/passwd.

Hmm. I'm not fan of estimating working set size by calculation based on some numbers without considering history or feedback.

Quoted 7 lines

Quoted 3 lines

Can't we use some kind of feedback algorithm as hi-low-watermark, random walk or GA (or somehing more smart) to detect the size ?

Could you please clarify at what level you are suggesting size detection? I assume it is outside the OS, right?

"OS" includes kernel and system programs ;)

I can think of both way in kernel and in user approarh and they should be complement to each other.

An example of kernel-based approach is.
1. add a shrinker callback(A) for balloon-driver-for-guest as guest kswapd.
2. add a shrinker callback(B) for balloon-driver-for-host as host kswapd.
(I guess current balloon driver is only for host. Please imagine.)

(A) increases free memory in Guest.
(B) increases free memory in Host.

This is an example of feedback based memory resizing between host and guest.

I think (B) is necessary at least before considering complecated things.

To implement something clever, (A) and (B) should take into account that how frequently memory reclaim in guest (which requires some I/O) happens.

If doing outside kernel, I think using memcg is better than depends on balloon driver. But co-operative balloon and memcg may show us something good.

Quoted 10 lines · Balbir Singh

Quoted 6 lines

I'm not sure victimizing unmapped cache pages is a good idea. Shouldn't page selection use the LRU for recency information instead of the cost of guest reclaim? Dropping a frequently used unmapped cache page can be more expensive than dropping an unused text page that was loaded as part of some executable's initialization and forgotten.

We victimize the unmapped cache only if it is unused (in LRU order). We don't force the issue too much. We also have free slab cache to go after.

Just to be clear, let's say we have a mapped page (say of /sbin/init) that's been unreferenced since _just_ after the system booted. We also have an unmapped page cache page of a file often used at runtime, say one from /etc/resolv.conf or /etc/passwd.

Which page will be preferred for eviction with this patch set?

Quoted 9 lines

Just to be clear, let's say we have a mapped page (say of /sbin/init) that's been unreferenced since _just_ after the system booted. We also have an unmapped page cache page of a file often used at runtime, say one from /etc/resolv.conf or /etc/passwd.

Which page will be preferred for eviction with this patch set?

In this case the order is as follows

1. First we pick free pages if any
2. If we don't have free pages, we go after unmapped page cache and slab cache
3. If that fails as well, we go after regularly memory

In the scenario that you describe, we'll not be able to easily free up the frequently referenced page from /etc/*. The code will move on to step 3 and do its regular reclaim.

Quoted 10 lines · Balbir Singh

Quoted 8 lines

Just to be clear, let's say we have a mapped page (say of /sbin/init) that's been unreferenced since _just_ after the system booted. We also have an unmapped page cache page of a file often used at runtime, say one from /etc/resolv.conf or /etc/passwd.

Which page will be preferred for eviction with this patch set?

In this case the order is as follows

Quoted 8 lines

1. First we pick free pages if any
2. If we don't have free pages, we go after unmapped page cache and slab cache
3. If that fails as well, we go after regularly memory

In the scenario that you describe, we'll not be able to easily free up the frequently referenced page from /etc/*. The code will move on to step 3 and do its regular reclaim.

Still it seems to me you are subverting the normal order of reclaim. I don't see why an unmapped page cache or slab cache item should be evicted before a mapped page. Certainly the cost of rebuilding a dentry compared to the gain from evicting it, is much higher than that of reestablishing a mapped page.

Quoted 12 lines

Quoted 12 lines

In this case the order is as follows

1. First we pick free pages if any
2. If we don't have free pages, we go after unmapped page cache and slab cache
3. If that fails as well, we go after regularly memory

In the scenario that you describe, we'll not be able to easily free up the frequently referenced page from /etc/*. The code will move on to step 3 and do its regular reclaim.

Quoted 7 lines

Still it seems to me you are subverting the normal order of reclaim. I don't see why an unmapped page cache or slab cache item should be evicted before a mapped page. Certainly the cost of rebuilding a dentry compared to the gain from evicting it, is much higher than that of reestablishing a mapped page.

Subverting to aviod memory duplication, the word subverting is overloaded,

let me try to reason a bit. First let me explain the problem

Memory is a precious resource in a consolidated environment. We don't want to waste memory via page cache duplication (cache=writethrough and cache=writeback mode).

Now here is what we are trying to do

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.
2. In the case of page cache (specifically unmapped page cache), there is duplication already, so why not go after unmapped page caches when the system is under memory pressure?

In the case of 1, we don't force a dentry to be freed, but rather a freed page in the slab cache to be reclaimed ahead of forcing reclaim of mapped pages.

Does the problem statement make sense? If so, do you agree with 1 and 2? Is there major concern about subverting regular reclaim? Does subverting it make sense in the duplicated scenario?

Quoted 11 lines · Balbir Singh

Quoted 11 lines

Quoted 11 lines

In this case the order is as follows

1. First we pick free pages if any
2. If we don't have free pages, we go after unmapped page cache and slab cache
3. If that fails as well, we go after regularly memory

In the scenario that you describe, we'll not be able to easily free up the frequently referenced page from /etc/*. The code will move on to step 3 and do its regular reclaim.

Quoted 8 lines

Quoted 6 lines

Still it seems to me you are subverting the normal order of reclaim. I don't see why an unmapped page cache or slab cache item should be evicted before a mapped page. Certainly the cost of rebuilding a dentry compared to the gain from evicting it, is much higher than that of reestablishing a mapped page.

Subverting to aviod memory duplication, the word subverting is overloaded,

Right, should have used a different one.

Quoted 17 lines

let me try to reason a bit. First let me explain the problem

Memory is a precious resource in a consolidated environment. We don't want to waste memory via page cache duplication (cache=writethrough and cache=writeback mode).

Now here is what we are trying to do

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.
2. In the case of page cache (specifically unmapped page cache), there is duplication already, so why not go after unmapped page caches when the system is under memory pressure?

Quoted 3 lines

In the case of 1, we don't force a dentry to be freed, but rather a freed page in the slab cache to be reclaimed ahead of forcing reclaim of mapped pages.

Sounds like this should be done unconditionally, then. An empty slab page is worth less than an unmapped pagecache page at all times, no?

Quoted 4 lines

Does the problem statement make sense? If so, do you agree with 1 and 2? Is there major concern about subverting regular reclaim? Does subverting it make sense in the duplicated scenario?

In the case of 2, how do you know there is duplication? You know the guest caches the page, but you have no information about the host. Since the page is cached in the guest, the host doesn't see it referenced, and is likely to drop it.

If there is no duplication, then you may have dropped a recently-used page and will likely cause a major fault soon.

Quoted 23 lines

Quoted 23 lines

let me try to reason a bit. First let me explain the problem

Memory is a precious resource in a consolidated environment. We don't want to waste memory via page cache duplication (cache=writethrough and cache=writeback mode).

Now here is what we are trying to do

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.
2. In the case of page cache (specifically unmapped page cache), there is duplication already, so why not go after unmapped page caches when the system is under memory pressure?

In the case of 1, we don't force a dentry to be freed, but rather a freed page in the slab cache to be reclaimed ahead of forcing reclaim of mapped pages.

Quoted 5 lines

Sounds like this should be done unconditionally, then. An empty slab page is worth less than an unmapped pagecache page at all times, no?

In a consolidated environment, even at the cost of some CPU to run shrinkers, I think potentially yes.

Quoted 10 lines

Quoted 5 lines

Does the problem statement make sense? If so, do you agree with 1 and 2? Is there major concern about subverting regular reclaim? Does subverting it make sense in the duplicated scenario?

In the case of 2, how do you know there is duplication? You know the guest caches the page, but you have no information about the host. Since the page is cached in the guest, the host doesn't see it referenced, and is likely to drop it.

True, that is why the first patch is controlled via a boot parameter that the host can pass. For the second patch, I think we'll need something like a balloon<size> <cache?> with the cache argument being optional.

Quoted 3 lines

If there is no duplication, then you may have dropped a recently-used page and will likely cause a major fault soon.

Yes, agreed.

If we drop unmapped pagecache pages, we need to be sure they can be backed by the host, and that depends on the amount of sharing.

Quoted 3 lines · Avi Kivity

If we drop unmapped pagecache pages, we need to be sure they can be backed by the host, and that depends on the amount of sharing.

You also have to set up the host up properly, and continue to maintain it in a way that finds and eliminates duplicates.

I saw some benchmarks where KSM was doing great, finding lots of duplicate pages. Then, the host filled up, and guests started reclaiming. As memory pressure got worse, so did KSM's ability to find duplicates.

At the same time, I see what you're trying to do with this. It really can be an alternative to ballooning if we do it right, since ballooning would probably evict similar pages. Although it would only work in idle guests, what about a knob that the host can turn to just get the guest to start running reclaim?

Quoted 5 lines · Dave Hansen

At the same time, I see what you're trying to do with this. It really can be an alternative to ballooning if we do it right, since ballooning would probably evict similar pages. Although it would only work in idle guests, what about a knob that the host can turn to just get the guest to start running reclaim?

Isn't the knob in this proposal the balloon? AFAICT, the idea here is to change how the guest reacts to being ballooned, but the trigger itself would not change.

My issue is that changing the type of object being preferentially reclaimed just changes the type of workload that would prematurely suffer from reclaim. In this case, workloads that use a lot of unmapped pagecache would suffer.

btw, aren't /proc/sys/vm/swapiness and vfs_cache_pressure similar knobs?

Quoted 8 lines · Avi Kivity

Quoted 6 lines · Dave Hansen

At the same time, I see what you're trying to do with this. It really can be an alternative to ballooning if we do it right, since ballooning would probably evict similar pages. Although it would only work in idle guests, what about a knob that the host can turn to just get the guest to start running reclaim?

Quoted 4 lines

Isn't the knob in this proposal the balloon? AFAICT, the idea here is to change how the guest reacts to being ballooned, but the trigger itself would not change.

I think the patch was made on the following assumptions:
1. Guests will keep filling their memory with relatively worthless page cache that they don't really need.
2. When they do this, it hurts the overall system with no real gain for anyone.

In the case of a ballooned guest, they _won't_ keep filling memory. The balloon will prevent them. So, I guess I was just going down the path of considering if this would be useful without ballooning in place. To me, it's really hard to justify _with_ ballooning in place.

Quoted 5 lines

My issue is that changing the type of object being preferentially reclaimed just changes the type of workload that would prematurely suffer from reclaim. In this case, workloads that use a lot of unmapped pagecache would suffer.

Quoted 2 lines

btw, aren't /proc/sys/vm/swapiness and vfs_cache_pressure similar knobs?

Those tell you how to balance going after the different classes of things that we can reclaim.

Again, this is useless when ballooning is being used. But, I'm thinking of a more general mechanism to force the system to both have MemFree _and_ be acting as if it is under memory pressure.

Quoted 16 lines · Dave Hansen

Quoted 9 lines · Avi Kivity

Quoted 5 lines · Dave Hansen

At the same time, I see what you're trying to do with this. It really can be an alternative to ballooning if we do it right, since ballooning would probably evict similar pages. Although it would only work in idle guests, what about a knob that the host can turn to just get the guest to start running reclaim?

Isn't the knob in this proposal the balloon? AFAICT, the idea here is to change how the guest reacts to being ballooned, but the trigger itself would not change.

I think the patch was made on the following assumptions:
1. Guests will keep filling their memory with relatively worthless page cache that they don't really need.
2. When they do this, it hurts the overall system with no real gain for anyone.

Quoted 4 lines

In the case of a ballooned guest, they _won't_ keep filling memory. The balloon will prevent them. So, I guess I was just going down the path of considering if this would be useful without ballooning in place. To me, it's really hard to justify _with_ ballooning in place.

There are two decisions that need to be made:

- how much memory a guest should be given
- given some guest memory, what's the best use for it

The first question can perhaps be answered by looking at guest I/O rates and giving more memory to more active guests. The second question is hard, but not any different than running non-virtualized
- except if we can detect sharing or duplication. In this case, dropping a duplicated page is worthwhile, while dropping a shared page provides no benefit.

How the patch helps answer either question, I'm not sure. I don't think preferential dropping of unmapped page cache is the answer.

Quoted 5 lines

Quoted 5 lines

My issue is that changing the type of object being preferentially reclaimed just changes the type of workload that would prematurely suffer from reclaim. In this case, workloads that use a lot of unmapped pagecache would suffer.

Quoted 7 lines

Quoted 1 line

btw, aren't /proc/sys/vm/swapiness and vfs_cache_pressure similar knobs?

Those tell you how to balance going after the different classes of things that we can reclaim.

Again, this is useless when ballooning is being used. But, I'm thinking of a more general mechanism to force the system to both have MemFree _and_ be acting as if it is under memory pressure.

If there is no memory pressure on the host, there is no reason for the guest to pretend it is under pressure. If there is memory pressure on the host, it should share the pain among its guests by applying the balloon. So I don't think voluntarily dropping cache is a good direction.

Quoted 6 lines

There are two decisions that need to be made:

- how much memory a guest should be given
- given some guest memory, what's the best use for it

Quoted 7 lines

The first question can perhaps be answered by looking at guest I/O rates and giving more memory to more active guests. The second question is hard, but not any different than running non-virtualized
- except if we can detect sharing or duplication. In this case, dropping a duplicated page is worthwhile, while dropping a shared page provides no benefit.

I think there is another way of looking at it, give some free memory

1. Can the guest run more applications or run faster

2. Can the host potentially get this memory via ballooning or some other means to start newer guest instances

I think the answer to 1 and 2 is yes.

Quoted 4 lines

How the patch helps answer either question, I'm not sure. I don't think preferential dropping of unmapped page cache is the answer.

Preferential dropping as selected by the host, that knows about the setup and if there is duplication involved. While we use the term preferential dropping, remember it is still via LRU and we don't always succeed. It is a best effort (if you can and the unmapped pages are not highly referenced) scenario.

Quoted 7 lines

Quoted 7 lines

Those tell you how to balance going after the different classes of things that we can reclaim.

Again, this is useless when ballooning is being used. But, I'm thinking of a more general mechanism to force the system to both have MemFree _and_ be acting as if it is under memory pressure.

Quoted 7 lines

If there is no memory pressure on the host, there is no reason for the guest to pretend it is under pressure. If there is memory pressure on the host, it should share the pain among its guests by applying the balloon. So I don't think voluntarily dropping cache is a good direction.

There are two situations

1. Voluntarily drop cache, if it was setup to do so (the host knows that it caches that information anyway)

2. Drop the cache on either a special balloon option, again the host knows it caches that very same information, so it prefers to free that up first.

Quoted 14 lines · Balbir Singh

Quoted 6 lines

There are two decisions that need to be made:

- how much memory a guest should be given
- given some guest memory, what's the best use for it

Quoted 6 lines

The first question can perhaps be answered by looking at guest I/O rates and giving more memory to more active guests. The second question is hard, but not any different than running non-virtualized
- except if we can detect sharing or duplication. In this case, dropping a duplicated page is worthwhile, while dropping a shared page provides no benefit.

I think there is another way of looking at it, give some free memory

Quoted 1 line

1. Can the guest run more applications or run faster

That's my second question. How to best use this memory. More applications == drop the page from cache, faster == keep page in cache.

All we need is to select the right page to drop.

Quoted 2 lines

2. Can the host potentially get this memory via ballooning or some other means to start newer guest instances

Well, we already have ballooning. The question is can we improve the eviction algorithm.

Quoted 10 lines

I think the answer to 1 and 2 is yes.

Quoted 3 lines

How the patch helps answer either question, I'm not sure. I don't think preferential dropping of unmapped page cache is the answer.

Preferential dropping as selected by the host, that knows about the setup and if there is duplication involved. While we use the term preferential dropping, remember it is still via LRU and we don't always succeed. It is a best effort (if you can and the unmapped pages are not highly referenced) scenario.

How can the host tell if there is duplication? It may know it has some pagecache, but it has no idea whether or to what extent guest pagecache duplicates host pagecache.

Quoted 12 lines

Quoted 12 lines

Quoted 6 lines

Those tell you how to balance going after the different classes of things that we can reclaim.

Again, this is useless when ballooning is being used. But, I'm thinking of a more general mechanism to force the system to both have MemFree _and_ be acting as if it is under memory pressure.

If there is no memory pressure on the host, there is no reason for the guest to pretend it is under pressure. If there is memory pressure on the host, it should share the pain among its guests by applying the balloon. So I don't think voluntarily dropping cache is a good direction.

Quoted 4 lines

There are two situations

1. Voluntarily drop cache, if it was setup to do so (the host knows that it caches that information anyway)

It doesn't, really. The host only has aggregate information about itself, and no information about the guest.

Dropping duplicate pages would be good if we could identify them. Even then, it's better to drop the page from the host, not the guest, unless we know the same page is cached by multiple guests.

But why would the guest voluntarily drop the cache? If there is no memory pressure, dropping caches increases cpu overhead and latency even if the data is still cached on the host.

Quoted 3 lines

2. Drop the cache on either a special balloon option, again the host knows it caches that very same information, so it prefers to free that up first.

Dropping in response to pressure is good. I'm just not convinced the patch helps in selecting the correct page to drop.

Quoted 4 lines

All we need is to select the right page to drop.

Do we need to drop to the granularity of the page to drop? I think figuring out the class of pages and making sure that we don't write our own reclaim logic, but work with what we have to identify the class of pages is a good start.

Quoted 5 lines

How can the host tell if there is duplication? It may know it has some pagecache, but it has no idea whether or to what extent guest pagecache duplicates host pagecache.

Well it is possible in host user space, I for example use memory cgroup and through the stats I have a good idea of how much is duplicated. I am ofcourse making an assumption with my setup of the cached mode, that the data in the guest page cache and page cache in the cgroup will be duplicated to a large extent. I did some trivial experiments like drop the data from the guest and look at the cost of bringing it in and dropping the data from both guest and host and look at the cost. I could see a difference.

Unfortunately, I did not save the data, so I'll need to redo the experiment.

Quoted 8 lines

It doesn't, really. The host only has aggregate information about itself, and no information about the guest.

Dropping duplicate pages would be good if we could identify them. Even then, it's better to drop the page from the host, not the guest, unless we know the same page is cached by multiple guests.

On the exact pages to drop, please see my comments above on the class of pages to drop.

There are reasons for wanting to get the host to cache the data

Unless the guest is using cache = none, the data will still hit the host page cache
The host can do a better job of optimizing the writeouts

Quoted 5 lines

But why would the guest voluntarily drop the cache? If there is no memory pressure, dropping caches increases cpu overhead and latency even if the data is still cached on the host.

So, there are basically two approaches

1. First patch, proactive - enabled by a boot option
2. When ballooned, we try to (please NOTE try to) reclaim cached pages first. Failing which, we go after regular pages in the alloc_page() call in the balloon driver.

Quoted 8 lines

Quoted 4 lines

2. Drop the cache on either a special balloon option, again the host knows it caches that very same information, so it prefers to free that up first.

Dropping in response to pressure is good. I'm just not convinced the patch helps in selecting the correct page to drop.

That is why I've presented data on the experiments I've run and provided more arguments to backup the approach.

Quoted 3 lines · Balbir Singh

Quoted 3 lines

All we need is to select the right page to drop.

Quoted 4 lines

Do we need to drop to the granularity of the page to drop? I think figuring out the class of pages and making sure that we don't write our own reclaim logic, but work with what we have to identify the class of pages is a good start.

Well, the class of pages are 'pages that are duplicated on the host'. Unmapped page cache pages are 'pages that might be duplicated on the host'. IMO, that's not close enough.

Quoted 13 lines

Quoted 4 lines

How can the host tell if there is duplication? It may know it has some pagecache, but it has no idea whether or to what extent guest pagecache duplicates host pagecache.

Well it is possible in host user space, I for example use memory cgroup and through the stats I have a good idea of how much is duplicated. I am ofcourse making an assumption with my setup of the cached mode, that the data in the guest page cache and page cache in the cgroup will be duplicated to a large extent. I did some trivial experiments like drop the data from the guest and look at the cost of bringing it in and dropping the data from both guest and host and look at the cost. I could see a difference.

Quoted 2 lines

Unfortunately, I did not save the data, so I'll need to redo the experiment.

I'm sure we can detect it experimentally, but how do we do it programatically at run time (without dropping all the pages). Situations change, and I don't think we can infer from a few experiments that we'll have a similar amount of sharing. The cost of an incorrect decision is too high IMO (not that I think the kernel always chooses the right pages now, but I'd like to avoid regressions from the unvirtualized state).

btw, when running with a disk controller that has a very large cache, we might also see duplication between "guest" and host. So, if this is a good idea, it shouldn't be enabled just for virtualization, but for any situation where we have a sizeable cache behind us.

Quoted 9 lines

Quoted 7 lines

It doesn't, really. The host only has aggregate information about itself, and no information about the guest.

Dropping duplicate pages would be good if we could identify them. Even then, it's better to drop the page from the host, not the guest, unless we know the same page is cached by multiple guests.

On the exact pages to drop, please see my comments above on the class of pages to drop.

Well, we disagree about that. There is some value in dropping duplicated pages (not always), but that's not what the patch does. It drops unmapped pagecache pages, which may or may not be duplicated.

Quoted 1 line

There are reasons for wanting to get the host to cache the data

There are also reasons to get the guest to cache the data - it's more efficient to access it in the guest.

Quoted 3 lines

Unless the guest is using cache = none, the data will still hit the host page cache
The host can do a better job of optimizing the writeouts

True, especially for non-raw storage. But even there we have to fsync all the time to keep the metadata right.

Quoted 10 lines

Quoted 4 lines

But why would the guest voluntarily drop the cache? If there is no memory pressure, dropping caches increases cpu overhead and latency even if the data is still cached on the host.

So, there are basically two approaches

1. First patch, proactive - enabled by a boot option
2. When ballooned, we try to (please NOTE try to) reclaim cached pages first. Failing which, we go after regular pages in the alloc_page() call in the balloon driver.

Doesn't that mean you may evict a RU mapped page ahead of an LRU unmapped page, just in the hope that it is double-cached?

Maybe we need the guest and host to talk to each other about which pages to keep.

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

2. Drop the cache on either a special balloon option, again the host knows it caches that very same information, so it prefers to free that up first.

Dropping in response to pressure is good. I'm just not convinced the patch helps in selecting the correct page to drop.

That is why I've presented data on the experiments I've run and provided more arguments to backup the approach.

I'm still unconvinced, sorry.

Quoted 4 lines

Again, this is useless when ballooning is being used. But, I'm thinking of a more general mechanism to force the system to both have MemFree _and_ be acting as if it is under memory pressure.

If there is no memory pressure on the host, there is no reason for the guest to pretend it is under pressure.

If there is memory pressure on
the host, it should share the pain among its guests by applying the balloon. So I don't think voluntarily dropping cache is a good direction.

Quoted 5 lines · Avi Kivity

Quoted 5 lines

Again, this is useless when ballooning is being used. But, I'm thinking of a more general mechanism to force the system to both have MemFree _and_ be acting as if it is under memory pressure.

Quoted 3 lines

If there is no memory pressure on the host, there is no reason for the guest to pretend it is under pressure.

I can think of quite a few places where this would be beneficial.

Ballooning is dangerous. I've OOMed quite a few guests by over-ballooning them. Anything that's voluntary like this is safer than things imposed by the host, although you do trade of effectiveness.

If all the guests do this, then it leaves that much more free memory on the host, which can be used flexibly for extra host page cache, new guests, etc...

A system in this state where everyone is proactively keeping their footprints down is more likely to be able to handle load spikes.

Reclaim is an expensive, costly activity, and this ensures that we don't have to do that when we're busy doing other things like handling load spikes.

This was one of the concepts behind CMM2: reduce
the overhead during peak periods.

It's also handy for planning. Guests exhibiting this behavior will _act_ as if they're under pressure. That's a good thing to approximate how a guest will act when it _is_ under pressure.

Quoted 4 lines

If there is memory pressure on
the host, it should share the pain among its guests by applying the balloon. So I don't think voluntarily dropping cache is a good direction.

I think we're trying to consider things slightly outside of ballooning at this point. If ballooning was the end-all solution, I'm fairly sure Balbir wouldn't be looking at this stuff. Just trying to keep options open. :)

Quoted 12 lines · Dave Hansen

Quoted 8 lines · Avi Kivity

Quoted 5 lines

Again, this is useless when ballooning is being used. But, I'm thinking of a more general mechanism to force the system to both have MemFree _and_ be acting as if it is under memory pressure.

If there is no memory pressure on the host, there is no reason for the guest to pretend it is under pressure.

I can think of quite a few places where this would be beneficial.

Quoted 3 lines

Ballooning is dangerous. I've OOMed quite a few guests by over-ballooning them. Anything that's voluntary like this is safer than things imposed by the host, although you do trade of effectiveness.

That's a bug that needs to be fixed. Eventually the host will come under pressure and will balloon the guest. If that kills the guest, the ballooning is not effective as a host memory management technique.

Quoted 3 lines

If all the guests do this, then it leaves that much more free memory on the host, which can be used flexibly for extra host page cache, new guests, etc...

If the host detects lots of pagecache misses it can balloon guests down. If pagecache is quiet, why change anything?

If the host wants to start new guests, it can balloon guests down. If no new guests are wanted, why change anything?

Quoted 5 lines

That's a bug that needs to be fixed. Eventually the host will come under pressure and will balloon the guest. If that kills the guest, the ballooning is not effective as a host memory management technique.

I'm not convinced that it's just a bug that can be fixed. Consider a case where a host sees a guest with 100MB of free memory at the exact moment that a database app sees that memory. The host tries to balloon that memory away at the same time that the app goes and allocates it. That can certainly lead to an OOM very quickly, even for very small amounts of memory (much less than 100MB). Where's the bug?

I think the issues are really fundamental to ballooning.

Quoted 7 lines

Quoted 4 lines

If all the guests do this, then it leaves that much more free memory on the host, which can be used flexibly for extra host page cache, new guests, etc...

If the host detects lots of pagecache misses it can balloon guests down. If pagecache is quiet, why change anything?

Page cache misses alone are not really sufficient. This is the classic problem where we try to differentiate streaming I/O (which we can't effectively cache) from I/O which can be effectively cached.

Quoted 3 lines

If the host wants to start new guests, it can balloon guests down. If no new guests are wanted, why change anything?

We're talking about an environment which we're always trying to optimize. Imagine that we're always trying to consolidate guests on to smaller numbers of hosts. We're effectively in a state where we _always_ want new guests.

Quoted 4 lines

We're talking about an environment which we're always trying to optimize. Imagine that we're always trying to consolidate guests on to smaller numbers of hosts. We're effectively in a state where we _always_ want new guests.

If this came at no cost to the guests, you'd be right. But at some point guest performance will be hit by this, so the advantage gained from freeing memory will be balanced by the disadvantage.

Also, memory is not the only resource. At some point you become cpu bound; at that point freeing memory doesn't help and in fact may increase your cpu load.

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.

Quoted 5 lines · Balbir Singh

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.

You don't have to be freeing entire slab pages for the reclaim to have been useful. You could just be making space so that _future_ allocations fill in the slab holes you just created. You may not be freeing pages, but you're reducing future system pressure.

If unmapped page cache is the easiest thing to evict, then it should be the first thing that goes when a balloon request comes in, which is the case this patch is trying to handle. If it isn't the easiest thing to evict, then we _shouldn't_ evict it.

Quoted 5 lines · Dave Hansen

Quoted 4 lines · Balbir Singh

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.

Quoted 4 lines

You don't have to be freeing entire slab pages for the reclaim to have been useful. You could just be making space so that _future_ allocations fill in the slab holes you just created. You may not be freeing pages, but you're reducing future system pressure.

Depends. If you've evicted something that will be referenced soon, you're increasing system pressure.

Quoted 14 lines · Avi Kivity

Quoted 12 lines · Dave Hansen

Quoted 5 lines · Balbir Singh

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.

You don't have to be freeing entire slab pages for the reclaim to have been useful. You could just be making space so that _future_ allocations fill in the slab holes you just created. You may not be freeing pages, but you're reducing future system pressure.

Quoted 4 lines

Depends. If you've evicted something that will be referenced soon, you're increasing system pressure.

I don't think slab pages care about being referenced soon, they are either allocated or freed. A page is just a storage unit for the data structure. A new one can be allocated on demand.

Quoted 4 lines · Balbir Singh

1. A slab page will not be freed until the entire page is free (all slabs have been kfree'd so to speak). Normal reclaim will definitely free this page, but a lot of it depends on how frequently we are scanning the LRU list and when this page got added.

You don't have to be freeing entire slab pages for the reclaim to have been useful. You could just be making space so that _future_ allocations fill in the slab holes you just created. You may not be freeing pages, but you're reducing future system pressure.

If unmapped page cache is the easiest thing to evict, then it should be the first thing that goes when a balloon request comes in, which is the case this patch is trying to handle. If it isn't the easiest thing to evict, then we _shouldn't_ evict it.

If you've got duplicate pages and you know
that they are duplicated and can be retrieved at a lower cost, why wouldn't we go after them first?

Quoted 3 lines · Balbir Singh

If you've got duplicate pages and you know
that they are duplicated and can be retrieved at a lower cost, why wouldn't we go after them first?

I agree with this in theory. But, the guest lacks the information about what is truly duplicated and what the costs are for itself and/or the host to recreate it. "Unmapped page cache" may be the best proxy that we have at the moment for "easy to recreate", but I think it's still too poor a match to make these patches useful.

Quoted 6 lines · Dave Hansen

Quoted 4 lines · Balbir Singh

If you've got duplicate pages and you know
that they are duplicated and can be retrieved at a lower cost, why wouldn't we go after them first?

Quoted 7 lines

I agree with this in theory. But, the guest lacks the information about what is truly duplicated and what the costs are for itself and/or the host to recreate it. "Unmapped page cache" may be the best proxy that we have at the moment for "easy to recreate", but I think it's still too poor a match to make these patches useful.

That is why the policy (in the next set) will come from the host. As to whether the data is truly duplicated, my experiments show up to 60% of the page cache is duplicated.

Quoted 12 lines · Balbir Singh

Quoted 10 lines · Dave Hansen

Quoted 3 lines · Balbir Singh

If you've got duplicate pages and you know
that they are duplicated and can be retrieved at a lower cost, why wouldn't we go after them first?

I agree with this in theory. But, the guest lacks the information about what is truly duplicated and what the costs are for itself and/or the host to recreate it. "Unmapped page cache" may be the best proxy that we have at the moment for "easy to recreate", but I think it's still too poor a match to make these patches useful.

Quoted 3 lines

That is why the policy (in the next set) will come from the host. As to whether the data is truly duplicated, my experiments show up to 60% of the page cache is duplicated.

Isn't that incredibly workload dependent?

We can't expect the host admin to know whether duplication will occur or not.

Quoted 11 lines

Quoted 5 lines

That is why the policy (in the next set) will come from the host. As to whether the data is truly duplicated, my experiments show up to 60% of the page cache is duplicated.

Isn't that incredibly workload dependent?

We can't expect the host admin to know whether duplication will occur or not.

I was referring to cache = (policy) we use based on the setup. I don't think the duplication is too workload specific. Moreover, we could use aggressive policies and restrict page cache usage or do it selectively on ballooning. We could also add other options to make the ballooning option truly optional, so that the system management software decides.

Quoted 6 lines · Balbir Singh

Quoted 6 lines

Quoted 4 lines

That is why the policy (in the next set) will come from the host. As to whether the data is truly duplicated, my experiments show up to 60% of the page cache is duplicated.

Isn't that incredibly workload dependent?

Quoted 8 lines

Quoted 3 lines

We can't expect the host admin to know whether duplication will occur or not.

I was referring to cache = (policy) we use based on the setup. I don't think the duplication is too workload specific. Moreover, we could use aggressive policies and restrict page cache usage or do it selectively on ballooning. We could also add other options to make the ballooning option truly optional, so that the system management software decides.

Consider a read-only workload that exactly fits in guest cache. Without trimming, the guest will keep hitting its own cache, and the host will see no access to the cache at all. So the host (assuming it is under even low pressure) will evict those pages, and the guest will happily use its own cache. If we start to trim, the guest will have to go to disk. That's the best case.

Now for the worst case. A random access workload that misses the cache on both guest and host. Now every page is duplicated, and trimming guest pages allows the host to increase its cache, and potentially reduce misses. In this case trimming duplicated pages works.

Real life will see a mix of this. Often used pages won't be duplicated, and less often used pages may see some duplication, especially if the host cache portion dedicated to the guest is bigger than the guest cache.

I can see that trimming duplicate pages helps, but (a) I'd like to be sure they are duplicates and (b) often trimming them from the host is better than trimming them from the guest.

Trimming from the guest is worthwhile if the pages are not used very often (but enough that caching them in the host is worth it) and if the host cache can serve more than one guest. If we can identify those pages, we don't risk degrading best-case workloads (as defined above).

(note ksm to some extent identifies those pages, though it is a bit expensive, and doesn't share with the host pagecache).