Suggestions on fixing fill_modes ioctl() delays under i915

Suggestions on fixing fill_modes ioctl() delays under i915

[Dan Aloni]

[-- Attachment #1.1: Type: text/plain, Size: 1880 bytes --]

Hello,

I'd like to assist in fixing an issue that is quite nagging concerning the
i915 driver. I wasn't sure whether to classify this as a bug, but it's
something worth considering. Let me explain.

When I first used the i915 driver on my Lenovo X220 laptop, I noticed that
every time I run xrandr, or when any X client tries to query the display
modes, the X server hangs for a second or so. Using systemtap, I was able
to track the hang to the Intel DRM driver, around the area in which it
talks over i2C in order to query the modes from display
controller. More specifically, drm_mode_getconnector() is calling i915's
->fill_modes() and it waits there for awhile.

Now you might ask why it is annoying. Well, for instance, say you are
debugging an SDL application. Those type of applications usually result in
the GET_CONTROLLERS ioctl() being called by the X server, and re-running
the same application in a development cycle makes this issue
quite noticeable.

To make my work bearable, I came as far as adding a sysfs kernel module
parameter to DRM for the purpose of force-disabling the condition of the
call to fill_mode(). Now imagine, I do 'echo  1  >
/sys/module/drm/parameters/dont_fill_modes', and voila, xrandr works like
charm, SDL apps don't get stuck on init. Good until I disconnect my laptop
from the display port, or until it suspends. YUCK. Of course we don't want
this approach, it's an ugly hack.

I am hoping that DRM/Intel developers might be able to come with a fix. I'd
be happy to leverage my kernel hacking skills for this. My setup is a Linux
3.2.11 vanilla, xserver-xorg 1:7.6+4ubuntu3.2, x86_64 on Lenovo X220,
PCI_ID 8086:0126 (rev 09). Problem is 100% reproducible, and happens
whether I'm directly connected without a docking station via DisplayPort,
or whether I'm using a docking station with a display connected to it by
DVI.

Thanks.
- Dan

[-- Attachment #1.2: Type: text/html, Size: 2207 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Suggestions on fixing fill_modes ioctl() delays under i915

[Eugeni Dodonov]

[-- Attachment #1.1: Type: text/plain, Size: 1043 bytes --]

On Mon, Apr 16, 2012 at 09:04, Dan Aloni <alonid@gmail.com> wrote:

> Hello,
>
> I'd like to assist in fixing an issue that is quite nagging concerning the
> i915 driver. I wasn't sure whether to classify this as a bug, but it's
> something worth considering. Let me explain.
>
> When I first used the i915 driver on my Lenovo X220 laptop, I noticed that
> every time I run xrandr, or when any X client tries to query the display
> modes, the X server hangs for a second or so. Using systemtap, I was able
> to track the hang to the Intel DRM driver, around the area in which it
> talks over i2C in order to query the modes from display controller.
>

Could you try using the 3.4-rc1 or newer kernel by a chance? The patch that
I initially sent in past October which improves the i2c interaction for
output detection over 'phantom' outputs went in there, and so far it seems
to improve the display detection timing by 30%-3000% (depending on hardware
of course and number of outputs and such).

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>

[-- Attachment #1.2: Type: text/html, Size: 1444 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Suggestions on fixing fill_modes ioctl() delays under i915

[Chris Wilson]

On Mon, 16 Apr 2012 15:04:50 +0300, Dan Aloni <alonid@gmail.com> wrote:
> Now you might ask why it is annoying. Well, for instance, say you are
> debugging an SDL application. Those type of applications usually result in
> the GET_CONTROLLERS ioctl() being called by the X server, and re-running
> the same application in a development cycle makes this issue
> quite noticeable.

The actual problem here is the application requesting a probe of all
outputs rather than the list of current outputs.
See RRGetScreenResourcesCurrent.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: Suggestions on fixing fill_modes ioctl() delays under i915

[Dan Aloni]

[-- Attachment #1.1: Type: text/plain, Size: 1396 bytes --]

On Mon, Apr 16, 2012 at 4:33 PM, Eugeni Dodonov <eugeni@dodonov.net> wrote:

> On Mon, Apr 16, 2012 at 09:04, Dan Aloni <alonid@gmail.com> wrote:
>
>> Hello,
>>
>> I'd like to assist in fixing an issue that is quite nagging concerning
>> the i915 driver. I wasn't sure whether to classify this as a bug, but it's
>> something worth considering. Let me explain.
>>
>> When I first used the i915 driver on my Lenovo X220 laptop, I noticed
>> that every time I run xrandr, or when any X client tries to query the
>> display modes, the X server hangs for a second or so. Using systemtap, I
>> was able to track the hang to the Intel DRM driver, around the area in
>> which it talks over i2C in order to query the modes from display controller.
>>
>
> Could you try using the 3.4-rc1 or newer kernel by a chance? The patch
> that I initially sent in past October which improves the i2c interaction
> for output detection over 'phantom' outputs went in there, and so far it
> seems to improve the display detection timing by 30%-3000% (depending on
> hardware of course and number of outputs and such).
>

Okay, with 3.4-rc3 I can confirm that it works much better. For the xrandr
test case, I've timed each ioctl to about 60 milli-secs with 9 calls
spanning over half a second. Any further suggestions? Isn't it possible to
tell that nothing is connected and then not try to probe those ports at all?

[-- Attachment #1.2: Type: text/html, Size: 2023 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Suggestions on fixing fill_modes ioctl() delays under i915

[Adam Jackson]

[-- Attachment #1.1: Type: text/plain, Size: 1373 bytes --]

On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote:

> Okay, with 3.4-rc3 I can confirm that it works much better. For the
> xrandr test case, I've timed each ioctl to about 60 milli-secs with 9
> calls spanning over half a second. Any further suggestions? Isn't it
> possible to tell that nothing is connected and then not try to probe
> those ports at all?

There could be such detection, but there is not.  We have hotplug
interrupts, but we don't trust them to actually tell us whether
something is connected.  (We don't trust them because we think they're
unreliable, and then they remain unreliable because we don't fix the
implementation to be trustworthy.)  We just turn the interrupts into
uevents and then rely on userspace to compensate for the kernel not
doing a good enough job.

Since we don't do that, the only way to tell that nothing is connected
is to probe.  We could make probing a bit faster by caching previous
EDID and memcmp'ing the first 16 bytes (which include the
vendor/model/serial tuple, which should be unique enough) instead of
retrying the whole EDID fetch unconditionally.

But, as Chris said: You probably want to fix SDL to use
GetScreenResourcesCurrent since GetScreenResources is really only meant
for the session's configuration manager; and if you're running xrandr by
hand, use xrandr --current.

- ajax

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Suggestions on fixing fill_modes ioctl() delays under i915

[Dan Aloni]

[-- Attachment #1.1: Type: text/plain, Size: 1918 bytes --]

On Mon, Apr 16, 2012 at 7:37 PM, Adam Jackson <ajax@redhat.com> wrote:

> On Mon, 2012-04-16 at 18:54 +0300, Dan Aloni wrote:
>
> > Okay, with 3.4-rc3 I can confirm that it works much better. For the
> > xrandr test case, I've timed each ioctl to about 60 milli-secs with 9
> > calls spanning over half a second. Any further suggestions? Isn't it
> > possible to tell that nothing is connected and then not try to probe
> > those ports at all?
>
> There could be such detection, but there is not.  We have hotplug
> interrupts, but we don't trust them to actually tell us whether
> something is connected.  (We don't trust them because we think they're
> unreliable, and then they remain unreliable because we don't fix the
> implementation to be trustworthy.)  We just turn the interrupts into
> uevents and then rely on userspace to compensate for the kernel not
> doing a good enough job.
>

Seems reasonable. Thought the hardware interfaces were better, though.


>
> Since we don't do that, the only way to tell that nothing is connected
> is to probe.  We could make probing a bit faster by caching previous
> EDID and memcmp'ing the first 16 bytes (which include the
> vendor/model/serial tuple, which should be unique enough) instead of
> retrying the whole EDID fetch unconditionally.
>

That would only accelerate the query on the ports that are connected, no?
A full probe on an unconnected port would still take time I assume.


>
> But, as Chris said: You probably want to fix SDL to use
> GetScreenResourcesCurrent since GetScreenResources is really only meant
> for the session's configuration manager; and if you're running xrandr by
> hand, use xrandr --current.
>
>
About SDL - I don't see any call to GetScreenResources in SDL's code.
Could it be another function causing those probes?

BTW, gnome-display-properties also seems to be causing the probe, do
you think it needs to be modified as well?

[-- Attachment #1.2: Type: text/html, Size: 2726 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx