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:	Fri, 8 Jun 2012 11:04:17 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	mathieu.desnoyers@...icios.com, josh@...htriplett.org,
	niv@...ibm.com, tglx@...utronix.de, peterz@...radead.org,
	rostedt@...dmis.org, Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, darren@...art.com, fweisbec@...il.com,
	patches@...aro.org
Subject: Re: [PATCH tip/core/rcu 0/7] RCU_FAST_NO_HZ changes for 3.6


* Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:

> Hello!
> 
> This patch series provides more adjustments to the (relatively) new
> large-system-safe implementation for RCU_FAST_NO_HZ:
> 
> 1.	Remove RCU_FAST_NO_HZ dependency on stop_machine() nature of
> 	CPU hotplug.
> 2.	Make RCU_FAST_NO_HZ tracing distinguish between short and
> 	long idle intervals.
> 3.	Move RCU_FAST_NO_HZ per-CPU state variables to the rcu_dynticks
> 	per-CPU structure.
> 4.	Precompute RCU_FAST_NO_HZ timer offsets so that the timers
> 	will actually be paid attention to.  This fixes the slow-boot
> 	problem that hit a few people.
> 5.	Convert ftrace_dump() calls in idle entry and idle exit from
> 	DUMP_ALL to DUMP_ORIG.
> 6.	Fix erroneous TINY_PREEMPT_RCU assumption that rcu_preempt_needs_cpu()
> 	is a quiescent state (it is not).
> 7.	Round RCU_FAST_NO_HZ lazy timeout to nearest second to conserve
> 	power on systems with synchronized scheduler-clock interrupts.
> 
> I am considering pushing #1-#4 into 3.5 for the slow-boot regression.
> If you object, please let me know.

Sure, that's sensible - could get this to me ASAP so that we can 
send it to Linus before -rc2? #3 and #4 are pretty large so we 
want them upstream ASAP.

Thanks,

	Ingo
--
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