public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: "Chris Wilson" <chris@chris-wilson.co.uk>,
	"Imre Deak" <imre.deak@intel.com>,
	intel-gfx@lists.freedesktop.org,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms
Date: Tue, 21 Feb 2017 10:06:45 +0000	[thread overview]
Message-ID: <d8869e59-0ef5-6cc4-8cad-7e1b6f8f2e2e@linux.intel.com> (raw)
In-Reply-To: <20170221093730.GR11809@nuc-i3427.alporthouse.com>


On 21/02/2017 09:37, Chris Wilson wrote:
> On Tue, Feb 21, 2017 at 11:22:12AM +0200, Imre Deak wrote:
>> On Mon, Feb 20, 2017 at 04:05:33PM +0000, Chris Wilson wrote:
>>> So that our preempt-off period doesn't grow completely unchecked, or do
>>> we need that 34ms loop?
>>
>> Yes, that's at least how I understand it. Scheduling away is what let's
>> PCODE start servicing some other request than ours or go idle. That's
>> in a way what we see when the preempt-enabled poll times out.
>
> I was thinking along the lines of if it was just busy/unavailable for the
> first 33ms that particular time, it just needed to sleep until ready.
> Once available, the next request ran in the expected 1ms.
>
> Do you not see any value in trying a sleeping loop? Perhaps compromise
> and have the preempt-disable timeout increase each iteration.

Parachuting in so apologies if I misunderstood something.

Is the issue here that we can get starved out of CPU time for more than 
33ms while waiting for an event?

Could we play games with sched_setscheduler and maybe temporarily go 
SCHED_DEADLINE or something? Would have to look into how to correctly 
restore to the old state from that and from which contexts we can 
actually end up in this wait.

Regards,

Tvrtko

  reply	other threads:[~2017-02-21 10:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 15:29 [PATCH] drm/i915/gen9: Increase PCODE request timeout to 100ms Imre Deak
2017-02-20 16:05 ` Chris Wilson
2017-02-21  9:22   ` Imre Deak
2017-02-21  9:37     ` Chris Wilson
2017-02-21 10:06       ` Tvrtko Ursulin [this message]
2017-02-21 12:43         ` [Intel-gfx] " Imre Deak
2017-02-21 13:11           ` Tvrtko Ursulin
2017-02-21 14:13             ` [Intel-gfx] " Imre Deak
2017-02-21 14:16               ` Tvrtko Ursulin
2017-02-21 13:19           ` [Intel-gfx] " Chris Wilson
2017-02-21 14:18             ` Imre Deak
2017-02-20 17:22 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-02-24 14:32 ` [PATCH v2] drm/i915/gen9: Increase PCODE request timeout to 50ms Imre Deak
2017-02-24 15:52 ` ✓ Fi.CI.BAT: success for drm/i915/gen9: Increase PCODE request timeout to 100ms (rev2) Patchwork
2017-02-24 19:18   ` Chris Wilson
2017-03-01 11:17   ` Imre Deak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d8869e59-0ef5-6cc4-8cad-7e1b6f8f2e2e@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=stable@vger.kernel.org \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox