Matthew Garrett on the race to idle

Matthew Garrett on the race to idle

Posted May 10, 2008 8:58 UTC (Sat) by farnz (guest, #17727)
In reply to: Matthew Garrett on the race to idle by mjg59
Parent article: Matthew Garrett on the race to idle

Unfortunately, this conflicts hard with real-time constraints; I work with a soft real-time system based on Linux, and I've had to disable dropping into deeper C-states. Our system includes a smooth text scroller, which works by updating the screen every frame (16 milliseconds); thanks to the high performance of X11 on Intel Q35, the update takes less than a millisecond, and then that thread goes to sleep until the next frame starts.

With the latest Intel processors, we found that the screen jerked, as there was nothing but this update on one core, and it was going into a low C-state as soon as the update completed, then not coming out of idle until too late.

I note that there's an in-kernel mechanism to let drivers tell the scheduler about their latency needs (allowing them to always be scheduled on the core that's not being put into a low C-state); it's a shame that there's no way for a process to do the same, yet.

---

(Log in to post comments)

I agree with that. Applications need to be able to indicate that they're unable to tolerate
latency, and the scheduler and CPU governor need to cope with the extra restriction. I've been
talking to some of the embedded people about this, in terms of what sort of userspace-visible
knobs we need for effective power management without screwing up userspace.

kernel/pm_qos_params.c provides an interface for communicating acceptable latencies.  (new in
2.6.25)

--mgross

... and it's built in unconditionally, even if you have no power 
management configured, which seems rather strange.

Weird, if your application needs to update the screen every 16ms, this means that you're using
some kind of timers to wake up every 16ms, so the kernel ought to be aware of this deadline
and change the C-state of the CPU accordingly..

Either I'm misunderstanding something or there is a bug somewhere, have you discussed this on
the LKML?

> We're not using timers at all - we use the DRM to wait for VBlank.

But then use X11 for rendering? If so, part of the reason for the latency being too high could
be the several context switches between the interrupt and the rendering operation taking
place. By using OpenGL with current Mesa and a current drm Git snapshot, it would be possible
to have the DRM emit the buffer swap operation from a tasklet triggered by the interrupt, and
the application could generate frames ahead of time and transparently sleep when it's too far
ahead.