linux-kernel - Re: Intel graphics CPU usage

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: <1281932956.3530.3.camel@clockmaker-el6>
Date:	Mon, 16 Aug 2010 14:29:16 +1000
From:	Dave Airlie <airlied@...hat.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Dave Airlie <airlied@...ux.ie>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	Zhao Yakui <yakui.zhao@...el.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Adam Jackson <ajax@...hat.com>, linux-kernel@...r.kernel.org,
	DRI mailing list <dri-devel@...ts.freedesktop.org>
Subject: Re: Intel graphics CPU usage - SDVO detect bogosity?

On Sun, 2010-08-15 at 21:01 -0700, Linus Torvalds wrote:
> On Sun, Aug 15, 2010 at 8:30 PM, Dave Airlie <airlied@...hat.com> wrote:
> >
> > At least we should replace mdelay with msleep in those functions.
> 
> How precise does the timing have to be? I think i2c is self-clocking,
> so it's ok to see big skews? Becuase msleep() can be off by quite a
> bit (mdelay can too, but it's _way_ more rare, and requires either a
> preemptible kernel or serious interrupt activity).

In this case it definitely doesn't matter, I expect msleep to be a much
nicer to the system in general idea esp in routines we can all at
runtime from userspace.

> 
> > Can you get a boot with drm.debug=4?
> 
> Sure. That results in a truncated dmesg (with a 128k buffer). The
> thing seems to spew out something every ten seconds:
> 
>   ...
>   [  232.610044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
>              (SDVO_CMD_GET_ATTACHED_DISPLAYS)
>   [  232.624504] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00
>              (Success)
>   [  232.624517] [drm:intel_sdvo_detect], SDVO response 1 0
>   [  232.624524] [drm:intel_sdvo_debug_write], SDVOB: W: 7A 01
>              (SDVO_CMD_SET_CONTROL_BUS_SWITCH)
>   [  242.672044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
>              (SDVO_CMD_GET_ATTACHED_DISPLAYS)
>   [  242.686503] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00
>              (Success)
>   [  242.686516] [drm:intel_sdvo_detect], SDVO response 1 0
>   [  242.686523] [drm:intel_sdvo_debug_write], SDVOB: W: 7A 01
>              (SDVO_CMD_SET_CONTROL_BUS_SWITCH)
>   [  252.750044] [drm:intel_sdvo_debug_write], SDVOB: W: 0B
>              (SDVO_CMD_GET_ATTACHED_DISPLAYS)
>   [  252.764526] [drm:intel_sdvo_debug_response], SDVOB: R: 01 00
>              (Success)
>   [  252.764539] [drm:intel_sdvo_detect], SDVO response 1 0
>   ...
> 
> It looks like it takes about 15 ms each time.  But 15 ms each 10s
> doesn't seem to be enough to account for the load average. Maybe it
> gets synchronized with the timer tick or something, causing the load
> average to look artificially inflated (it also doesn't match up with
> kworker using 1%+ CPU time).
> 
> So maybe there is something else going on. Maybe the load average
> thing comes from some interaction with the new workqueue thing.
> 
> I'll send the whole dmesg to you in a private message, I don't think
> we want 128kB of crud on lkml.
> 
> > I wonder are we picking up a bad SDVO, the insane code retries 50 times
> > with a hard loop delay.
> 
> Well, I'm not seeing any failures, but maybe those don't get printed out?

Oh wierd, so not where I thought it was, I expect then the SDVO HDMI
detection is completely insane,

intel_sdvo_hdmi_sink_detect looks to contain some really uninspiring
code. Might be worth adding some debug in there to see if it sinks a lot
of time.

Dave.

--
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/