cc: Add command line switch to control resource usage for impl-side painting.

cc/resources/resource_pool.cc

Index: cc/resources/resource_pool.cc
diff --git a/cc/resources/resource_pool.cc b/cc/resources/resource_pool.cc
index 3cd45d8d5d7d8d6f180900981adc4e3ea6f4e122..6bf03804a6117dde4ea4b0f9241d35f879eb8d6e 100644
--- a/cc/resources/resource_pool.cc
+++ b/cc/resources/resource_pool.cc
@@ -30,7 +30,8 @@ ResourcePool::Resource::~Resource() {
 ResourcePool::ResourcePool(ResourceProvider* resource_provider)
     : resource_provider_(resource_provider),
       max_memory_usage_bytes_(0),
-      memory_usage_bytes_(0) {
+      memory_usage_bytes_(0),
+      acquired_memory_usage_bytes_(0) {
 }
 
 ResourcePool::~ResourcePool() {
@@ -55,6 +56,7 @@ scoped_ptr<ResourcePool::Resource> ResourcePool::AcquireResource(
       continue;
 
     resources_.erase(it);
+    acquired_memory_usage_bytes_ += resource->bytes();
     return make_scoped_ptr(resource);
   }
 
@@ -68,11 +70,13 @@ scoped_ptr<ResourcePool::Resource> ResourcePool::AcquireResource(
   resource_provider_->EnableReadLockFences(resource->id(), true);
 
   memory_usage_bytes_ += resource->bytes();
+  acquired_memory_usage_bytes_ += resource->bytes();
   return make_scoped_ptr(resource);
 }
 
 void ResourcePool::ReleaseResource(
     scoped_ptr<ResourcePool::Resource> resource) {
+  acquired_memory_usage_bytes_ -= resource->bytes();
   if (memory_usage_bytes_ > max_memory_usage_bytes_) {
     memory_usage_bytes_ -= resource->bytes();
     return;
@@ -87,11 +91,31 @@ void ResourcePool::SetMaxMemoryUsageBytes(size_t max_memory_usage_bytes) {
   while (!resources_.empty()) {
     if (memory_usage_bytes_ <= max_memory_usage_bytes_)
       break;
-    Resource* resource = resources_.front();
-    resources_.pop_front();
-    memory_usage_bytes_ -= resource->bytes();
-    delete resource;
+
+    EvictOneResource();
+  }
+}
+
+void ResourcePool::ReduceMemoryUsage() {
+  size_t ten_percent_of_memory = max_memory_usage_bytes_ / 10;

[piman, 2013/03/25 18:13:46]

What would happen if we didn't try to keep anything?
10% of 1GB (the current limit on Chrome OS) is 100MB. I want to make sure 100MB
allocated per visible tab is worth whatever we hope to save in perf.

[reveman, 2013/03/25 18:36:06]

we have to pay the cost of allocating texture, pixel-transfer-buffer and query
more frequently. so basically some shallow flushes and whatever driver side cost
we have for creating a new texture. this might not be too bad on chromeos but
excessive amounts of cache misses for each pending tree activation will
undoubtedly have a performance impact.

I picked 10% as that's what we use in the old texture manager. I don't have any
data showing that this is the right number. I've only done some minimal testing
and not seen a significant perf impact.

[nduca, 2013/03/25 18:37:49]

How does this compare to a "please drop everything" policy? I'm really leery of
a memory managment strategy that drops some but not everything.

If you see a difference between the two, can we use the
allow_nothing/minimum/prepaint/anything policy instead? And ideally tie them
together more closely?

[reveman, 2013/03/25 18:47:33]

if we drop everything then initializing a new pending tree will be more costly
as we'll have to create new resources for every single tile. it might affect
active tree performance a bit too with the current read lock fences as we can't
reuse textures that we recently used for drawing.
sg, I forgot that we had that.

+  while (!resources_.empty()) {
+    size_t wasted_usage_bytes =
+        memory_usage_bytes_ - acquired_memory_usage_bytes_;
+    if (wasted_usage_bytes <= ten_percent_of_memory)
+      break;
+
+    EvictOneResource();
   }
 }
 
+void ResourcePool::EvictOneResource() {
+  DCHECK(!resources_.empty());
+  // MRU eviction pattern as least recently used is less likely to
+  // be blocked by read lock fence.
+  Resource* resource = resources_.back();
+  resources_.pop_back();
+  memory_usage_bytes_ -= resource->bytes();
+  delete resource;
+}
+
 }  // namespace cc