linux-kernel - Re: Bootup time regression from 2.6.27 to 2.6.28-rc3+

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:	Sat, 15 Nov 2008 10:04:04 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	Frans Pop <elendil@...net.nl>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Lukas Hejtmanek <xhejtman@....muni.cz>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Marcin Slusarz <marcin.slusarz@...il.com>,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	corsac@...ian.org, auke.kok@...el.com
Subject: Re: Bootup time regression from 2.6.27 to 2.6.28-rc3+

On Sat, 15 Nov 2008 18:16:31 +0100
Frans Pop <elendil@...net.nl> wrote:

> On Friday 14 November 2008, Frans Pop wrote:
> > > Find below the lineup of the timers-fixes-for-linus branch of the
> > > tip tree (the same as Arjan posted minus the irq fixes)
> >
> > Could either of you maybe give a status update on this patch set and
> > the remaining issues with it that were reported (especially the
> > high C0 reported by powertop)?
> 
> I guess part of the answer is:
> commit ae99286b4f1be7788f2d6947c66a91dbd6351eec
> Author: Thomas Gleixner <tglx@...utronix.de>
> Date:   Mon Nov 10 13:20:23 2008 +0100
>     nohz: disable tick_nohz_kick_tick() for now
> 
> I've just done some testing using v2.6.28-rc4-322-g58e20d8 which
> includes this patch.
> 
> CPU usage reported by powertop is now normal again (close to 100% in 
> lowest C state), but I'm still getting high counts for:
> - <kernel IPI> : Rescheduling interrupts
>   Typically 3-5 on .26/.27; 15-17 on .28.

these are caused by the scheduler, not by the timer code.
(And sometimes they're caused by the scheduler on behalf of something
else even)

> - <interrupt>  : extra timer interrupt
>   Consistently more prominent for .28 (though not with high values)

if it's less than 5 total, don't worry about it, some of that can well
be rounding/measurement effects
(powertop has to make a few approximations around the edges of the
measurement interval because things don't always line up perfectly)

>   than for .27, but way better than for .26.
> 
> 
> powertop questions
> ------------------
> - What's with this change from "polling" to "C0" for the 2nd C state?

that sounds like an interesting bug...

>   After boot I always (both when booted on mains and on battery) get
>   "polling", but after inserting or removing mains it will continue to
>   show "C0" independent of any further power state changes.
> - After switching to battery the first time I get something like:
>   C1                0.0ms (614891469122.
>   This is reproducible. I guess a rounding error due to the change in
>   the number of C states. Later updates clear this.

yeah it's annoying but it is only for one display period

> - Looks like someone could not make up his mind between comma and
> slash here: "(long term: 26.2W,/1.6h)"

that sounds easy to fix ;-)

Thanks for the bugreports; either me or Auke will take a look at these
shortly.

-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/