On Wed, Jan 22, 2014 at 11:04:28AM -0800, Keith Packard wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
The solution employed here is to undo the busy demotion after a period
of idleness. Currently the idle boost is applied only once for a fresh
client when it becomes selectable. The
Chris Wilson ch...@chris-wilson.co.uk writes:
Wouldn't smart_stop_tick be a slightly better choice as that gives us
the time the client became idle?
Yeah, that makes more semantic sense. Of course, in reality because
those two values are within one 'tick' of each other, it shouldn't have
a
On Thu, Jan 23, 2014 at 08:56:37AM -0800, Keith Packard wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
Wouldn't smart_stop_tick be a slightly better choice as that gives us
the time the client became idle?
Yeah, that makes more semantic sense. Of course, in reality because
those
Chris Wilson ch...@chris-wilson.co.uk writes:
I tested both. The difference, as could be expected, was in the noise.
Either patch fixes the problem I encountered.
I've pushed the one using smart_stop_tick.
76b275d..c1ce807 master - master
--
keith.pack...@intel.com
pgpXlhCT1DidY.pgp
Chris Wilson ch...@chris-wilson.co.uk writes:
The solution employed here is to undo the busy demotion after a period
of idleness. Currently the idle boost is applied only once for a fresh
client when it becomes selectable. The change is to apply that boost for
all clients that remain ready
Given the right mix of clients competing for server time, it is possible
for some of those clients to be starved. In a CPU bound system,
executing clients consume their entire ScheduleSlice and are demoted for
being busy. These clients then may block waiting for a reply from the
XServer freeing up
