linux-kernel - Re: [PATCH 1/4] nohz: Force boot CPU outside full dynticks range

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: <CAFTL4hzfNdSb3+uOmTfGiH3mOsZcs0jtphUxLpSNs5VhsEb_ig@mail.gmail.com>
Date:	Thu, 28 Mar 2013 14:08:35 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Chris Metcalf <cmetcalf@...era.com>,
	Christoph Lameter <cl@...ux.com>,
	Geoff Levand <geoff@...radead.org>,
	Gilad Ben Yossef <gilad@...yossef.com>,
	Hakan Akkan <hakanakkan@...il.com>,
	Kevin Hilman <khilman@...aro.org>,
	Li Zhong <zhong@...ux.vnet.ibm.com>,
	Namhyung Kim <namhyung.kim@....com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/4] nohz: Force boot CPU outside full dynticks range

2013/3/28 Ingo Molnar <mingo@...nel.org>:
>
> * Frederic Weisbecker <fweisbec@...il.com> wrote:
>
>> The timekeeping job must be able to run early on boot
>> because there may be some pre-SMP (and thus pre-initcalls )
>> components that rely on it. The IO-APIC is one such users
>> as it tests the timer health by watching jiffies progression.
>
> Btw., while I agree that a conservative mode is probably wise for bootup,
> that IO-APIC assumption could be fixed or even removed.
>
> If the IO-APIC code wants to know whether an interrupt fired, it can take
> a look at the kstat_irqs numbers?

Good point. Still I need to let timekeeping working early to avoid
more surprises.

>
> Also, could we restrict the boot CPU's mode only during the early bootup
> stage - i.e. until we are ready to execute user-space init?

That's a tricky issue. Let's consider the boot CPU is the timekeeper
in the beginning. Later reassigning the timekeeping duty to another
CPU require some careful treatment because we may do that remotely and
we want to keep tick_do_timer_cpu lockless. This may involve an IPI
coupled with proper memory ordering if we don't want to race with
dynticks idle (or even full dynticks).

It's on the long term plan but I thought about dealing with that later
once we get the basic feature working. But if you prefer I can work on
that now.
--
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/