[Bug 94722] [SKL/KBL] Init time is high

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94722

--- Comment #20 from Chris Wilson <chris at chris-wilson.co.uk> ---
(In reply to David Weinehall from comment #19)
> Measurements using SuspendResume on a KBL-Y yields roughly these numbers:
> 
> suspend: 320ms -- out of this 300ms is spent turning off panel + backlight;
> the delays here cannot be optimised away, so at most we can shave off a few
> milliseconds. This values will vary greatly depending on the panel used.
> 
> resume: 470ms -- out of this 30ms is spent in restore_gtt, 230ms is spent
> turning on panel + backlight, 170ms on probing for new displays, and 30ms in
> one of the opregion-related calls.

Could you test https://patchwork.freedesktop.org/patch/82422/ that should help
the restore_gtt slightly.

> The probing for new displays can be parallelised once the atomic modeset
> code is finalised. There are various other things that can be optimised here
> too, as the numbers probably show, but -- and here's the important part, for
> resume we are not blocking the critical path. There are several components
> that take longer to resume, and they are resuming in parallel to our driver.

Actually improving the logic to show the graph and the length of the critical
path would help your argument immensely and should allow efforts to be focused
on shortening the critical path. i.e. replace using initcall_debug alone with
scripts/bootgraph.pl.

But we should assume the ideal case where all other time is 0, and i915.ko is
the critical path.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20160503/7c719676/attachment.html>