(2011/12/19 18:26), Avi Kivity wrote:
On 12/19/2011 11:22 AM, Takuya Yoshikawa wrote:
Yes, it's very conservative. But on the other hand the shrinker is
tuned for dcache and icache, where there are usually tons of useless
objects. If we have to free something, I'd rather free them instead of
mmu pages which tend to get recreated soon.
OK, to satisfy the requirements, I will do:
1. find the guest with the highest (shadow pages / memory) ratio
How do you propose to do that efficiently? We may have hundreds of
guests, or even more, on one host. Each guest access will involve
bouncing a few cache lines.
IMO, The goal should be restricted to emergencies.
So possible solution may be:
- we set the tuning parameters as conservative as possible
- pick up a guest with relatively high ratio
(I have to think more how to achieve this)
- move the vm_list head for fairness
In an emergency, we should not mind performance penalty so much.
2. just zap one page from that guest, keeping the current
conservative rate
I will update the patch.
I think the current rate is too conservative. No idea what a good one
is, I don't have a feeling as to the relation between shrinker callbacks
and memory pressure.
When I tried to see what the current code is doing, frankly speaking,
I thought mmu_shrink() was not tested enough from the beginning.
I read the shrinker code as far as possible and realized the combination of
(seeks=10*default, batch=128) is not reasonable; the high seeks means the
shrinker rarely calculate higher value than 128, and mmu_shrink() cannot
be called in normal life.
How about setting the batch a bit lower, keeping seeks as is?
But there is not a perfect value because how often mmu_shrink() can be called
will change if the admin change the sysctl_vfs_cache_pressure tuning parameter
for dcache and icache, IIUC.
And tdp and shadow paging differ much.
Takuya
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
