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 18:16:31 +0100
From:	Frans Pop <elendil@...net.nl>
To:	Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...radead.org>
Cc:	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
Subject: Re: Bootup time regression from 2.6.27 to 2.6.28-rc3+

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.
- <interrupt>  : extra timer interrupt
  Consistently more prominent for .28 (though not with high values)
  than for .27, but way better than for .26.

The attachment shows top wakeups between .26.3, .27.4 and .28-rc4-322 for 
comparison. There are no significant differences between running on mains 
or on battery, but it does show some powertop weirdness.

powertop questions
------------------
- What's with this change from "polling" to "C0" for the 2nd C state?
  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.
- Looks like someone could not make up his mind between comma and slash
  here: "(long term: 26.2W,/1.6h)"

Cheers,
FJP


View attachment "powertop.txt" of type "text/plain" (6116 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ