On 10/30/2015 11:23 AM, Daniel Vetter wrote:
On Fri, Oct 30, 2015 at 02:42:44AM -0700, Thomas Hellstrom wrote:
Reduce the time in hardware irq context and hardware irq latency.
Signed-off-by: Thomas Hellstrom thellstrom@vmware.com Reviewed-by: Sinclair Yeh syeh@vmware.com
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 108 ++++++++++++++++++++-------------- drivers/gpu/drm/vmwgfx/vmwgfx_fence.h | 2 + drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 6 +- 3 files changed, 68 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 8e689b4..f40c36e 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -47,6 +47,7 @@ struct vmw_fence_manager { bool seqno_valid; /* Protected by @lock, and may not be set to true without the @goal_irq_mutex held. */ unsigned ctx;
- struct tasklet_struct tasklet;
Bottom halves are super-deprecated except for giant existing users like networking. I think the recommended way to do this is to either use threaded interrupts or work-queues. The reason for that seems to be that locking is funky around them, which is a major pain for RT. And RT is going mainline now for real. -Daniel
Thanks for the heads up. Unfortunately work-queues introduce too much latency for this use-case. Given that we (vmwgfx) already is an existing user (albeit not giant :)), and RT in a VM guest is somewhat unlikely I wonder how much of an issue this is.
I'll read up on threaded interrupts.
/Thomas