[Intel-gfx] [PATCH v5 26/35] drm/i915: Added debugfs interface to scheduler tuning parameters

[Jesse Barnes]

On 03/11/2016 08:28 AM, John Harrison wrote:
> On 23/02/2016 21:06, Jesse Barnes wrote:
>> On 02/18/2016 06:27 AM, John.C.Harrison at Intel.com wrote:
>>> From: John Harrison <John.C.Harrison at Intel.com>
>>>       struct drm_info_node *node = m->private;
>>> @@ -5424,6 +5587,12 @@ static const struct i915_debugfs_files {
>>>       {"i915_gem_drop_caches", &i915_drop_caches_fops},
>>>       {"i915_error_state", &i915_error_state_fops},
>>>       {"i915_next_seqno", &i915_next_seqno_fops},
>>> +    {"i915_scheduler_priority_min", &i915_scheduler_priority_min_fops},
>>> +    {"i915_scheduler_priority_max", &i915_scheduler_priority_max_fops},
>>> +    {"i915_scheduler_priority_bump",
>>> &i915_scheduler_priority_bump_fops},
>>> +    {"i915_scheduler_priority_preempt",
>>> &i915_scheduler_priority_preempt_fops},
>>> +    {"i915_scheduler_min_flying", &i915_scheduler_min_flying_fops},
>>> +    {"i915_scheduler_file_queue_max",
>>> &i915_scheduler_file_queue_max_fops},
>>>       {"i915_display_crc_ctl", &i915_display_crc_ctl_fops},
>>>       {"i915_pri_wm_latency", &i915_pri_wm_latency_fops},
>>>       {"i915_spr_wm_latency", &i915_spr_wm_latency_fops},
>>>
>> Do these need to be serialized at all?  I guess some raciness doesn't
>> hurt too much for these guys, unless somehow an inconsistent set of
>> values would cause a livelock in the scheduler or something.
> Serialised with what? Each other or the scheduler operation? Neither
> should be necessary. The scheduler will read the current values whenever
> it tests against one of these limits. If multiple are being changed
> while the system is busy, it doesn't really matter. They are just tuning
> values and best guesses type of numbers not array indices or other
> things that would cause kernel panics if you got them wrong. E.g. if you
> set the max file queue depth to smaller than the current queue contents
> that just means you won't be able to submit more stuff until the queue
> has drained - which is presumably the intended result of lowering the
> max queue value anyway. The queue won't leak the extra entries or get
> into an inconsistent state.

Yeah I meant both serialized against scheduler accesses/usage and
atomicity with respect to one another.  Sounds like it doesn't matter
too much though, so it's fine with me.

Jesse