Chrome Version: master
OS: Linux

The gpu::Scheduler doesn't have any aging mechanism to bump long waiting low priority tasks.

We have seen starvation in certain scenarios involving a test setup which includes using the software GL renderer (--override-use-software-gl-for-tests) in combination with running chromevox in a separate renderer process.

Essentially the chromevox render get stuck in startup waiting for response from the GpuCommandBufferMsg_WaitForGetOffsetInRange IPC message. The related command stream has priority kGpuStreamPriorityWorker.
There is a stream with priority kGpuStreamPriorityUI that get most of the scheduled time.

Not knowing this code very well (at all) I have two possible suggestions for a solution:
1) Implement aging in the scheduler. Seems generally good to make sure total starvation does not happen but could maybe be tricky to get a mechanism working well for all possible scenarios.
2) Temporary bump sequences that receive sync WaitForGetOffsetInRange (possibly others) messages to make sure we don't lock up clients. This would solve our particular problem scenario but may not catch all problems that could comes from this.