Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Antonio Argenziano <antonio.argenziano@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [Intel-gfx] [PATCH i-g-t 2/3] lib: Align ring measurement to timer
Date: Thu, 31 May 2018 07:42:03 -0700	[thread overview]
Message-ID: <758aadb2-6c7c-0f39-16e2-e2bfa3614886@intel.com> (raw)
In-Reply-To: <152770993249.8336.6150465185645684194@mail.alporthouse.com>



On 30/05/18 12:52, Chris Wilson wrote:
> Quoting Antonio Argenziano (2018-05-30 18:30:36)
>>
>>
>> On 30/05/18 03:33, Chris Wilson wrote:
>>> After hitting the SIGINT from execbuf, wait until the next timer signal
>>> before trying again. This aligns the start of the ioctl to the timer,
>>> hopefully maximising the amount of time we have for processing before
>>> the next signal -- trying to prevent the case where we are scheduled out
>>> in the middle of processing and so hit the timer signal too early.
>>>
>>> References: https://bugs.freedesktop.org/show_bug.cgi?id=106695
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>
>> Not sure I understand what is the sequence of events, is the problem we
>> get a signal in the middle of a 'good' execbuf and exit the while loop
>> prematurely? If so maybe we can also think of making the timer 'VIRTUAL'
>> so that it would decrement only when the process is executing.
> 
> If it's VIRTUAL it'll never fire when we wait for space (as being asleep
> no user/sys time is consumed).
> 
> The only way I can explain 106695 would be with some very strange
> scheduler behaviour, but even then it requires us to hit a path where we
> actually check for a pending signal -- which should only happen when we
> run out of ring space for this setup. Not even the device being wedged
> (which it wasn't) would cause the ring to drain. Possibly going over 10s
> and the cork being unplugged? Very stange.

Just a bit concerned that we might be covering up some weird corner case 
where we are sleeping where we shouldn't.

But the patch does what advertised and seems sensible so:

Acked-by: Antonio Argenziano <antonio.argenziano@intel.com>

> 
>>> ---
>>>    lib/i915/gem_ring.c | 2 ++
>>>    1 file changed, 2 insertions(+)
>>>
>>> diff --git a/lib/i915/gem_ring.c b/lib/i915/gem_ring.c
>>> index 7d64165eb..0c061000c 100644
>>> --- a/lib/i915/gem_ring.c
>>> +++ b/lib/i915/gem_ring.c
>>> @@ -96,6 +96,8 @@ __gem_measure_ring_inflight(int fd, unsigned int engine, enum measure_ring_flags
>>>                if (last == count)
>>>                        break;
>>>    
>>> +             /* sleep until the next timer interrupt (woken on signal) */
>>> +             pause();
>>
>> Does it cause any (sensible) slowdown?
> 
> Adds at most one timer interval, 10us. Ok, at a push 2 timer intervals
> if it takes longer than first to setup the sleep.
> -Chris
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2018-05-31 14:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-30 10:33 [Intel-gfx] [PATCH i-g-t 1/3] lib: Assert that we do manage to submit at least one batch when measuring Chris Wilson
2018-05-30 10:33 ` [igt-dev] [PATCH i-g-t 2/3] lib: Align ring measurement to timer Chris Wilson
2018-05-30 17:30   ` [Intel-gfx] " Antonio Argenziano
2018-05-30 19:52     ` Chris Wilson
2018-05-31 14:42       ` Antonio Argenziano [this message]
2018-05-31 14:56         ` [igt-dev] " Chris Wilson
2018-05-30 10:33 ` [igt-dev] [PATCH i-g-t 3/3] lib: Double check ring measurement Chris Wilson
2018-05-30 17:42   ` Antonio Argenziano
2018-05-31 16:57     ` Chris Wilson
2018-05-30 12:23 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/3] lib: Assert that we do manage to submit at least one batch when measuring Patchwork
2018-05-30 13:56 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2018-05-30 16:27 ` [igt-dev] [PATCH i-g-t 1/3] " Antonio Argenziano

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=758aadb2-6c7c-0f39-16e2-e2bfa3614886@intel.com \
    --to=antonio.argenziano@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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