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]

Date:	Sun, 15 Aug 2010 21:01:57 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Dave Airlie <airlied@...hat.com>
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, 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).

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

                        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/