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@xxxxxxxxx wrote:
From: Akash Goel <akash.goel@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
