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] [day] [month] [year] [list]
Date:	Sun, 08 Apr 2012 05:58:31 -0000
From:	Michael Witten <mfwitten@...il.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	John Stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Len Brown <lenb@...nel.org>,
	Arjan van de Ven <arjanvandeven@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] clocksource: Load the ACPI PM clocksource asynchronously

On Mon, 30 Jan 2012 20:51:20 -0800, Arjan van de Ven wrote:

> ...
>
> The ACPI clocksource takes quite some time to initialize,
> and this increases the boot time of the kernel for a
> double digit percentage. This while almost all modern
> systems will be using the HPET already anyway.
>
> This patch turns the clocksource loading into an asynchronous
> operation; which means it won't hold up the boot while
> still becoming available normally.
>
> To make this work well, an udelay() had to be turned into an
> usleep_range() so that on UP systems, we yield the CPU to
> regular boot tasks instead of spinning.
>
> ...

This patch became the following commit:

  commit b519508298e0292e1771eecf14aaf67755adc39d
  Author:     Arjan van de Ven <arjan@...ux.intel.com>
  AuthorDate: Mon Jan 30 20:23:30 2012 -0800
  Commit:     John Stultz <john.stultz@...aro.org>
  CommitDate: Wed Feb 1 18:39:46 2012 -0800

to which I bisected as the culprit for very strange load balance
behavior on my machine.

With this patch in place, my CPU is constantly being pegged at 100%
(and my CPU monitor sometimes registers NaN%), regardless of the
active governor and under conditions when my computer would normally
be idling quite placidly.

Reverting this commit does indeed remove the problem from previously
problematic builds.

Sincerely,
Michael Witten

Some probably useless information:

  * Dell Latitude D810 (from about 2005/2006)

      * BIOS Version A05

  * /proc/cpuinfo:

      processor       : 0
      vendor_id       : GenuineIntel
      cpu family      : 6
      model           : 13
      model name      : Intel(R) Pentium(R) M processor 2.13GHz
      stepping        : 8
      microcode       : 0x20
      cpu MHz         : 800.000
      cache size      : 2048 KB
      fdiv_bug        : no
      hlt_bug         : no
      f00f_bug        : no
      coma_bug        : no
      fpu             : yes
      fpu_exception   : yes
      cpuid level     : 2
      wp              : yes
      flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx bts est tm2
      bogomips        : 1596.47
      clflush size    : 64
      cache_alignment : 64
      address sizes   : 32 bits physical, 32 bits virtual
      power management:
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ