Re: [PATCH 13/17] drm/i915: New lock to serialize the Host2GuC actions

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 18/07/16 12:31, Goel, Akash wrote:
>
>
> On 7/18/2016 4:48 PM, Tvrtko Ursulin wrote:
>>
>> On 18/07/16 11:46, Goel, Akash wrote:
>>> On 7/18/2016 3:42 PM, Tvrtko Ursulin wrote:
>>>>
>>>> On 15/07/16 16:51, Goel, Akash wrote:
>>>>>
>>>>>
>>>>> On 7/15/2016 5:10 PM, Tvrtko Ursulin wrote:
>>>>>>
>>>>>> On 10/07/16 14:41, akash.goel@intel.com wrote:
>>>>>>> From: Akash Goel <akash.goel@intel.com>
>>>>>>>
>>>>>>> With the addition of new Host2GuC actions related to GuC logging,
>>>>>>> there
>>>>>>> is a need of a lock to serialize them, as they can execute
>>>>>>> concurrently
>>>>>>> with each other and also with other existing actions.
>>>>>>
>>>>>> After which patch in this series is this required?
>>>>>>
>>>>>  From patch 6 or 7 saw the problem, when enabled flush interrupts from
>>>>> boot (guc_log_level >= 0).
>>>>
>>>> That means this patch should come before 6 or 7. :)
>>>>
>>>>> Also new HOST2GUC actions LOG_BUFFER_FILE_FLUSH_COMPLETE &
>>>>> UK_LOG_ENABLE_LOGGING can execute concurrently with each other.
>>>>
>>>> Right I see, from the worker/thread vs debugfs activity.
>>>>
>>> Will use mutex to serialize and place the patch earlier in the series.
>>> Please suggest which would be better,
>>> mutex_lock()
>>> or
>>> mutex_lock_interruptible().
>>
>> Interruptible from the debugfs paths, otherwise not.
>
> Yes calls from debugfs path should ideally use interruptible version,
> but then how to determine that whether the given host2guc_action call
> came from debugfs path.
> Should I add a new argument 'interruptible_wait' to host2guc_action() or
> to keep things simple use mutex_lock() only ?
> I thought it would be cleaner to abstract the lock usage, for
> serialization, entirely inside the host2guc_action only.

Hm yes, good point. I think a simple mutex lock should be fine then. You 
don't expect to be holding it for more than 10ms in the absolutely worst 
case and I think simplicity of the implementation wins in this case even 
if it stalls userspace a bit.

Regards,

Tvrtko


_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx