linux-kernel - Re: responsiveness: newer kernels causing lagging and blocking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFxO27oa+WAtDLuWtr-NFNmKb2T0V6pccn=AE+g5PePPUg@mail.gmail.com>
Date:	Thu, 23 Feb 2012 10:15:24 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Chris Wilson <chris@...is-wilson.co.uk>
Cc:	stephan.baerwolf@...ilmenau.de, linux-kernel@...r.kernel.org,
	Michael Buesch <mb@...sch.de>,
	Alex Deucher <alexdeucher@...il.com>,
	Dave Airlie <airlied@...hat.com>
Subject: Re: responsiveness: newer kernels causing lagging and blocking

On Thu, Feb 23, 2012 at 9:21 AM, Chris Wilson <chris@...is-wilson.co.uk> wrote:
>
> The second is to break the loop for fatal errors, which is addressed by
>
> commit 9292f37e1f5c79400254dca46f83313488093825
> Author: Eugeni Dodonov <eugeni.dodonov@...el.com>
> Date:   Thu Jan 5 09:34:28 2012 -0200
>
>    drm: give up on edid retries when i2c bus is not responding

So I tried cherry-picking this one commit on top of current -git on
one of those nasty Mac Mini's.

I'm sad to report that I don't get anywhere *close* to the reported
performance numbers. Are there other commits involved that I should
have tried?

>    Timing results for i915-powered machines for 'time xrandr' command:
>    Machine 1: from 0.840s to 0.290s
>    Machine 2: from 0.315s to 0.280s
>    Machine 3: from +/- 4s to 0.184s
>
>    Timing results for HD5770 with 'time xrandr' command:
>    Machine 4: from 3.210s to 1.060s

On that Mac Mini, I get 0.611s before, and 0.553s after. So it does
seem to improve, but not nearly enough.

Part of the problem seems to be the bogus "TV1 unknown connection",
which just isn't true (and probably due to some insane Apple
connection setup). So I suspect something just doesn't get a proper
EDID, and times out or fails, and falls back to some bogus default. I
get

  TV1 unknown connection (normal left inverted right x axis y axis)
     1024x768       60.0
     800x600        60.3
     640x480        59.9

and I'm pretty sure there's no TV attached unless it is hiding under
the carpet somehow.

"perf record -a" shows that it's spending the time in udelay() as
expected (30% from intel_wait_for_pipe_off(), 30% from sclhi(), 30%
from bit_xfer() and 10% from acknak()). Which is what you'd expect
with that CPU-polling EDID thing.

So adding some scheduling might be a good idea regardless of that commit.

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