Re: [PATCH 2/4] drm/vmwgfx: Defer fence irq processing to a tasklet

[Thomas Hellstrom <thellstrom@vmware.com>]

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel