All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Jens Axboe <axboe@kernel.dk>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Eero Tamminen <eero.t.tamminen@intel.com>,
	"Rantala, Valtteri" <valtteri.rantala@intel.com>,
	stable@kernel.vger.org
Subject: Re: [PATCH 1/2] drm/i915: Break busywaiting for requests on pending signals
Date: Mon, 16 Nov 2015 11:40:25 +0000	[thread overview]
Message-ID: <5649C0A9.3030109@linux.intel.com> (raw)
In-Reply-To: <20151116112238.GR569@nuc-i3427.alporthouse.com>


On 16/11/15 11:22, Chris Wilson wrote:
> On Mon, Nov 16, 2015 at 09:54:10AM +0000, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 15/11/15 13:32, Chris Wilson wrote:
>>> The busywait in __i915_spin_request() does not respect pending signals
>>> and so may consume the entire timeslice for the task instead of
>>> returning to userspace to handle the signal.
>>
>> Obviously correct to break the spin, but if spending a jiffie to
>> react to signals was the only problem then it is not too severe.
>>
>> Add something to the commit message about how it was found/reported
>> and about the severity of impact, etc?
>
> Perhaps:
>
> At the worst case this could cause a delay in signal processing of 20ms,
> which would be a noticeable jitter in cursor tracking. If a higher
> resolution signal was being used, for example to provide fairness of a
> server timeslices between clients, we could expect to detect some
> unfairness between clients. This issue was noticed when inspecting a
> report of poor interactivity resulting from excessively high
> __i915_spin_request usage.

Oh its the Xorg scheduler tick... I always forget about that. Was 
thinking that it is only about fatal, or at least infrequent signals.

Regards,

Tvrtko

      reply	other threads:[~2015-11-16 11:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-15 13:32 [PATCH 1/2] drm/i915: Break busywaiting for requests on pending signals Chris Wilson
2015-11-15 13:32 ` Chris Wilson
2015-11-15 13:32 ` [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms! Chris Wilson
2015-11-15 13:32   ` Chris Wilson
2015-11-15 17:48   ` Chris Wilson
2015-11-15 17:48     ` Chris Wilson
2015-11-16 10:24   ` Tvrtko Ursulin
2015-11-16 10:24     ` Tvrtko Ursulin
2015-11-16 11:12     ` Chris Wilson
2015-11-16 11:12       ` Chris Wilson
2015-11-16 12:08       ` Tvrtko Ursulin
2015-11-16 12:08         ` Tvrtko Ursulin
2015-11-16 12:55         ` Chris Wilson
2015-11-16 12:55           ` Chris Wilson
2015-11-16 13:09           ` Tvrtko Ursulin
2015-11-16 13:09             ` Tvrtko Ursulin
2015-11-16 13:30           ` [Intel-gfx] " Ville Syrjälä
2015-11-16 13:30             ` Ville Syrjälä
2015-11-16 16:48   ` Jens Axboe
2015-11-18  9:56     ` Limit busywaiting Chris Wilson
2015-11-18  9:56       ` [PATCH 1/3] drm/i915: Only spin whilst waiting on the current request Chris Wilson
2015-11-18 17:03         ` Daniel Vetter
2015-11-19 10:05         ` Tvrtko Ursulin
2015-11-19 10:12           ` Chris Wilson
2015-11-18  9:56       ` [PATCH 2/3] drm/i915: Convert __i915_wait_request to receive flags Chris Wilson
2015-11-18  9:56       ` [PATCH 3/3] drm/i915: Limit request busywaiting Chris Wilson
2015-11-19 15:22         ` Daniel Vetter
2015-11-19 16:29       ` Limit busywaiting Jens Axboe
2015-12-03 22:03   ` [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms! Pavel Machek
2015-12-03 22:03     ` Pavel Machek
2015-11-16  9:54 ` [PATCH 1/2] drm/i915: Break busywaiting for requests on pending signals Tvrtko Ursulin
2015-11-16  9:54   ` Tvrtko Ursulin
2015-11-16 11:22   ` Chris Wilson
2015-11-16 11:22     ` Chris Wilson
2015-11-16 11:40     ` Tvrtko Ursulin [this message]

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=5649C0A9.3030109@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=axboe@kernel.dk \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eero.t.tamminen@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.vger.org \
    --cc=valtteri.rantala@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.