From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Mika Kuoppala <mika.kuoppala@linux.intel.com>,
Intel-gfx@lists.freedesktop.org,
Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH] drm/i915: Replace some more busy waits with normal ones
Date: Thu, 24 Mar 2016 13:06:41 +0000 [thread overview]
Message-ID: <56F3E661.7050805@linux.intel.com> (raw)
In-Reply-To: <20160324122731.GH27742@nuc-i3427.alporthouse.com>
On 24/03/16 12:27, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 11:37:07AM +0000, Tvrtko Ursulin wrote:
>>
>> On 23/03/16 16:40, Chris Wilson wrote:
>>> On Wed, Mar 23, 2016 at 04:24:48PM +0000, Tvrtko Ursulin wrote:
>>>> Biggest thing to make sure is that you don't add a lot of cycles to
>>>> the forcewake loops since for example fw_domains_get can be the
>>>> hottest i915 function on some benchmarks.
>>>>
>>>> (This area slightly annoys me anyway with redundant looping over
>>>> forcewake domains and we could also potentially optimize the ack
>>>> waiting by first requesting all we want, and then doing the waits.
>>>> That would be one additional loop, but if removed the other one,
>>>> code would stay at the same number of domain loops.)
>>>
>>> I hear you. I just end up weeping in the corner when I see fw_domain_get
>>> on the profile.
>>>
>>> We already do have a mitigation scheme to hold onto the forcewake for an
>>> extra jiffie every time. I don't like it, but without it fw_domains_get
>>> becomes a real hog.
>>
>> I am pretty sure I've seen some tests which somehow defeat the
>> jiffie delay and we end up re-acquiring every ms/jiffie. This is
>> something I wanted to get to the bottom of but did not get round to
>> yet. It was totally unexpected because the test is hammering on
>> everything.
>
> Absolutely sure it is not just the delay in acquiring the ack? And
> spinning on waiting for the thread_c0 doesn't come cheap? I've just
> written off fw_domain_get being high on the profiles simply due to that
> we have to spin so long (I'm jaded because on Sandybridge spinning for
> 50us+ isn't uncommon iirc).
I am not sure, I just know I had a printk in the timer release and it
was firing every millisecond which completely perplexed me since I was
running gem_exec_nop/all at the time.
Good point on that the cost might actually be in the wait for acks.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-24 13:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 14:32 [PATCH] drm/i915: Replace some more busy waits with normal ones Tvrtko Ursulin
2016-03-23 14:38 ` Tvrtko Ursulin
2016-03-23 15:43 ` Mika Kuoppala
2016-03-23 16:24 ` Tvrtko Ursulin
2016-03-23 16:40 ` Chris Wilson
2016-03-24 11:37 ` Tvrtko Ursulin
2016-03-24 12:27 ` Chris Wilson
2016-03-24 13:06 ` Tvrtko Ursulin [this message]
2016-03-24 13:16 ` Chris Wilson
2016-03-24 13:31 ` Chris Wilson
2016-03-23 14:50 ` kbuild test robot
2016-03-23 14:58 ` kbuild test robot
2016-03-23 15:03 ` ✗ Fi.CI.BAT: failure for " Patchwork
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=56F3E661.7050805@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=chris@chris-wilson.co.uk \
--cc=mika.kuoppala@linux.intel.com \
--cc=paulo.r.zanoni@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.