Re: [PATCH 1/3] drm/i915: don't block resume on fb console resume

From: Dave Airlie <airlied@gmail.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm/i915: don't block resume on fb console resume
Date: Mon, 15 Oct 2012 17:30:26 +1000	[thread overview]
Message-ID: <CAPM=9tz4Sgy2KWEH0j28=9VU02ypEp=KEvx3pmcc2dvzBaCCDg@mail.gmail.com> (raw)
In-Reply-To: <20121014214959.41260428@jbarnes-t420>

On Mon, Oct 15, 2012 at 2:49 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 15 Oct 2012 12:32:05 +1000
> Dave Airlie <airlied@gmail.com> wrote:
>
>> > The console lock can be contended, so rather than prevent other drivers
>> > after us from being held up, queue the console suspend into the global
>> > work queue that can happen anytime.  I've measured this to take around
>> > 200ms on my T420.  Combined with the ring freq/turbo change, we should
>> > save almost 1/2 a second on resume.
>>
>> Did you measure booting with quiet? I can't think what else could be
>> contending on this lock other than printk, now maybe we should reduce
>> the printk noise!
>>
>> This will make debugging things even worse than they are, since you
>> don't see any printks on the screen until after we do this.
>
> I thought I measured with quiet, but I'll double check.
>
> Not sure about debugging; it's pretty bad to begin with.  I generally
> use netconsole or the "stare really hard at the code" method when it
> comes to suspend/resume or init time anyway.
>
> But yeah, some investigation into the console lock contention is
> probably a good idea at any rate.  A typical distro config probably
> also has some other fbcon driver and probably vgacon built-in too, and
> I haven't checked what they do.
>

If they are still there at s/r time you now have two problems.

Dave.