Subject: Re: [PATCH 1/2] drm/i915: Break busywaiting for requests on pending
 signals
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
References: <1447594364-4206-1-git-send-email-chris@chris-wilson.co.uk>
 <5649A7C2.90206@linux.intel.com>
 <20151116112238.GR569@nuc-i3427.alporthouse.com>
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Organization: Intel Corporation UK Plc
Message-ID: <5649C0A9.3030109@linux.intel.com>
Date: Mon, 16 Nov 2015 11:40:25 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151116112238.GR569@nuc-i3427.alporthouse.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1472
Lines: 38


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/