[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGM2reZjKxiG+7P65=-sV7PdN_UepGT5QipWFScZ+TpAfDHQqQ@mail.gmail.com>
Date: Wed, 20 Jun 2018 17:30:17 -0400
From: Pavel Tatashin <pasha.tatashin@...cle.com>
To: peterz@...radead.org
Cc: tglx@...utronix.de, Steven Sistare <steven.sistare@...cle.com>,
Daniel Jordan <daniel.m.jordan@...cle.com>,
linux@...linux.org.uk, schwidefsky@...ibm.com,
Heiko Carstens <heiko.carstens@...ibm.com>,
John Stultz <john.stultz@...aro.org>, sboyd@...eaurora.org,
x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
mingo@...hat.com, hpa@...or.com, douly.fnst@...fujitsu.com,
prarit@...hat.com, feng.tang@...el.com,
Petr Mladek <pmladek@...e.com>, gnomes@...rguk.ukuu.org.uk
Subject: Re: [PATCH v10 7/7] x86/tsc: use tsc early
Hi Peter,
> That said; flipping static keys early isn't hard. We should call
> jump_label_init() early, because we want the entries sorted and the
> key->entries link set. It will also replace the GENERIC_NOP5_ATOMIC
> thing, which means we need to also do arch_init_ideal_nop() early, but
> since that is pure CPUID based that should be doable.
>
> And then something like the below could be used.
I like the idea of making static branches available early, as it can
be used in more places
during boot.
However, that should be part of a separate project, and a follow up
cleanup can be done
to places that benefit from it. Such as tsc.c and perhaps sched.c
might benefit as well.
Thank you,
Pavel
Powered by blists - more mailing lists