cc: Prevent the tile manager from allocating more memory than allowed.

cc: Prevent the tile manager from allocating more memory than allowed.

This adds a new ReduceMemoryUsage function to the resource pool. By
calling this function in TileManager::ScheduleTasks after creating
all resources needed to to call RasterWorkerPool::ScheduleTasks
we free enough unused resources to ensure that we never go above
the limit.

This also fixes the use of the num_resources_limit by correctly
accounting for all allocated resources.

BUG=273140
TEST=cc_unittests --gtest_filter=TileManagerTests/TileManagerTest.RespectMemoryLimit*

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=217951

[aelias_OOO_until_Jul13, 2013-08-15 02:05:59]

lgtm, thanks.

https://codereview.chromium.org/23231002/diff/1/cc/resources/resource_pool.h
File cc/resources/resource_pool.h (right):

https://codereview.chromium.org/23231002/diff/1/cc/resources/resource_pool.h#...
cc/resources/resource_pool.h:74: ResourceList resources_;
Please rename this to unused_resources_, that would've helped avoid my mistake
here.

[reveman, 2013-08-15 15:14:14]

https://codereview.chromium.org/23231002/diff/1/cc/resources/resource_pool.h
File cc/resources/resource_pool.h (right):

https://codereview.chromium.org/23231002/diff/1/cc/resources/resource_pool.h#...
cc/resources/resource_pool.h:74: ResourceList resources_;
On 2013/08/15 02:06:00, aelias wrote:
> Please rename this to unused_resources_, that would've helped avoid my mistake
> here.

Done.

[vmpstr, 2013-08-15 18:26:36]

https://codereview.chromium.org/23231002/diff/6001/cc/resources/resource_pool.cc
File cc/resources/resource_pool.cc (right):

https://codereview.chromium.org/23231002/diff/6001/cc/resources/resource_pool...
cc/resources/resource_pool.cc:118: bool ResourcePool::MemoryUsageTooHigh() {
nit: This should probably be ResourceUsageTooHigh (either from count or memory)

https://codereview.chromium.org/23231002/diff/6001/cc/resources/tile_manager.cc
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/23231002/diff/6001/cc/resources/tile_manager....
cc/resources/tile_manager.cc:715: resource_pool_->ReduceMemoryUsage();
I'm not sure I follow this. Wouldn't we want to ReduceMemoryUsage after
SchedulingTasks? There is no guarantee that ScheduleTasks won't take us over the
limit and in the case that we are currently over limit, we'll end up releasing a
bunch of resources only to create them again during ScheduleTasks (assuming same
format and size). Am I missing something?

[reveman, 2013-08-15 19:13:55]

https://codereview.chromium.org/23231002/diff/6001/cc/resources/resource_pool.cc
File cc/resources/resource_pool.cc (right):

https://codereview.chromium.org/23231002/diff/6001/cc/resources/resource_pool...
cc/resources/resource_pool.cc:118: bool ResourcePool::MemoryUsageTooHigh() {
On 2013/08/15 18:26:37, vmpstr wrote:
> nit: This should probably be ResourceUsageTooHigh (either from count or
memory)

Done. Together with other usage of "MemoryUsage" in ResourcePool class.

https://codereview.chromium.org/23231002/diff/6001/cc/resources/tile_manager.cc
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/23231002/diff/6001/cc/resources/tile_manager....
cc/resources/tile_manager.cc:715: resource_pool_->ReduceMemoryUsage();
On 2013/08/15 18:26:37, vmpstr wrote:
> I'm not sure I follow this. Wouldn't we want to ReduceMemoryUsage after
> SchedulingTasks? There is no guarantee that ScheduleTasks won't take us over
the
> limit and in the case that we are currently over limit, we'll end up releasing
a
> bunch of resources only to create them again during ScheduleTasks (assuming
same
> format and size). Am I missing something?

ScheduleTasks can't create new resources. It can only allocate the ones already
given to it.

So at this point we've already requested all resources that can be used by
ScheduleTasks and they are accounted for by the resource pool but they have not
yet been allocated as allocation is lazy. We've likely requested more resources
than allowed at this point as we might not have been able to recycle all unused
resources. This is good as it means the memory available to us is not affected
by our ability to recycle tiles and odd-sized tiles wont keep hanging around and
affect available memory. We just need to make sure we free enough unused
resources to stay below the limit before calling ScheduleTasks as that call will
cause real memory to be allocated.

[vmpstr, 2013-08-15 19:37:35]

> So at this point we've already requested all resources that can be used by
> ScheduleTasks and they are accounted for by the resource pool but they have
not
> yet been allocated as allocation is lazy. We've likely requested more
resources
> than allowed at this point as we might not have been able to recycle all
unused
> resources. This is good as it means the memory available to us is not affected
> by our ability to recycle tiles and odd-sized tiles wont keep hanging around
and
> affect available memory. We just need to make sure we free enough unused
> resources to stay below the limit before calling ScheduleTasks as that call
will
> cause real memory to be allocated.

Ah, my bad. I thought this was before TileManager::ScheduleTasks, but it's
before RWP::ScheduleTasks. Makes sense, lgtm.

[commit-bot: I haz the power, 2013-08-15 20:24:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/23231002/18001

[commit-bot: I haz the power, 2013-08-15 23:37:19]

Retried try job too often on win_rel for step(s) nacl_integration
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_rel&nu...

[commit-bot: I haz the power, 2013-08-16 01:17:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/reveman@chromium.org/23231002/35002

[commit-bot: I haz the power, 2013-08-16 05:48:01]

Change committed as 217951