linux-kernel - Re: Boot time regression in 2.6.38 after initial wq merge

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: <20110222090255.GR31267@htj.dyndns.org>
Date:	Tue, 22 Feb 2011 10:02:55 +0100
From:	Tejun Heo <tj@...nel.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	"pantherchen@...sanet.de" <pantherchen@...sanet.de>,
	linux-kernel@...r.kernel.org
Subject: Re: Boot time regression in 2.6.38 after initial wq merge

On Tue, Feb 22, 2011 at 12:52:23AM -0800, Dmitry Torokhov wrote:
> > 1. kworker/0:1's uninterruptible sleeps start later than kserio's.
> > 
> >    It could be that cpu 0 was busy running other stuff and thus cmwq
> >    delayed executing serio_event_work; however, if we look at the CPU
> >    usage, that doesn't seem likely.  The CPU is not busy at all and if
> >    the CPU isn't busy, cmwq wouldn't introduce any noticeable delay in
> >    work item execution.
> > 
> >    Another possibility is the rescuer concurrency depletion bug is
> >    delaying execution of queued work items early during boot.  This
> >    was fixed recently.  Can you please give a shot at 2.6.38-rc6 and
> >    see whether anything is different?
> > 
> > 2. Most of the delay is caused by xorg starting up much later.  xorg
> >    seems to start up in parallel with the kseriod sleeps in 2.6.37 but
> >    on 2.6.38 it seems to wait for the serio_event_work to finish.
> > 
> >    I have no idea what xorg is waiting for.  Dmitry, any clue?
> > 
> 
> It looks like it is not X is waiting but plymouth not being told to
> quit... I will have to look at waht triggers plymouth->X/GDM transition.
> 
> Also, serio jobs (mouse probe) is quite lengthtly. Should it be using
> unbound workqueue instead?

How long it works doesn't matter at all.  If you look at the boot
chart, as soon as those uninterruptible sleeps start, kworker/0:2 is
created to serve other work items, so it doesn't really affect anyone
else.  Unbound ones are mostly helpful for cases where the work items
involved may consume large amount of cpu cycles (not true here) over
long period of time.  That said, something definitely seems wrong
here.  Eh well, let's find out. :-)

Thanks.

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