Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1315848 > unrolled thread
| Started by | Borislav Petkov <bp@alien8.de> |
|---|---|
| First post | 2016-01-24 10:40 +0100 |
| Last post | 2016-01-25 20:00 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
[PATCH 6/6] x86/vdso: Use static_cpu_has() Borislav Petkov <bp@alien8.de> - 2016-01-24 10:40 +0100
Re: [PATCH 6/6] x86/vdso: Use static_cpu_has() Andy Lutomirski <luto@amacapital.net> - 2016-01-25 19:50 +0100
Re: [PATCH 6/6] x86/vdso: Use static_cpu_has() Borislav Petkov <bp@alien8.de> - 2016-01-25 20:00 +0100
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2016-01-24 10:40 +0100 |
| Subject | [PATCH 6/6] x86/vdso: Use static_cpu_has() |
| Message-ID | <qUpjk-2Lg-11@gated-at.bofh.it> |
From: Borislav Petkov <bp@suse.de> ... and simplify and speed up a tad. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@amacapital.net> --- arch/x86/entry/vdso/vma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c index 429d54d01b38..10f704584922 100644 --- a/arch/x86/entry/vdso/vma.c +++ b/arch/x86/entry/vdso/vma.c @@ -285,7 +285,7 @@ static void vgetcpu_cpu_init(void *arg) #ifdef CONFIG_NUMA node = cpu_to_node(cpu); #endif - if (cpu_has(&cpu_data(cpu), X86_FEATURE_RDTSCP)) + if (static_cpu_has(X86_FEATURE_RDTSCP)) write_rdtscp_aux((node << 12) | cpu); /* -- 2.3.5
[toc] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2016-01-25 19:50 +0100 |
| Message-ID | <qUUn8-8cw-19@gated-at.bofh.it> |
| In reply to | #1315848 |
On Sun, Jan 24, 2016 at 1:28 AM, Borislav Petkov <bp@alien8.de> wrote: > From: Borislav Petkov <bp@suse.de> > > ... and simplify and speed up a tad. This function is only used when initializing CPUs, so the "tad" is very small indeed. If there are systems for which some cpus support rdtscp and some don't, then this patch is wrong. Of course, if the bsp has rdtscp and the aps don't, then we're screwed anyway. I left it as cpu_has because this is a cpu init function and it seemed reasonable. That being said, I have no meaningful objection to this patch. --Andy
[toc] | [prev] | [next] | [standalone]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2016-01-25 20:00 +0100 |
| Message-ID | <qUUwO-8gR-3@gated-at.bofh.it> |
| In reply to | #1317178 |
We discussed this on IRC, here's the gist:
On Mon, Jan 25, 2016 at 10:45:30AM -0800, Andy Lutomirski wrote:
> On Sun, Jan 24, 2016 at 1:28 AM, Borislav Petkov <bp@alien8.de> wrote:
> > From: Borislav Petkov <bp@suse.de>
> >
> > ... and simplify and speed up a tad.
>
> This function is only used when initializing CPUs, so the "tad" is
> very small indeed.
... except it'll pay out when the branch is patched in. Considering
that the majority of the modern CPUs out there - BSP and APs :-) - have
RDTSCP, this check will turn into a 5-byte NOP which is the most optimal
we can get. Yeah, it is still an init path so called once on each CPU
but still.
> If there are systems for which some cpus support rdtscp and some
> don't, then this patch is wrong. Of course, if the bsp has rdtscp and
> the aps don't, then we're screwed anyway.
That would be a very odd case.
> I left it as cpu_has because this is a cpu init function and it seemed
> reasonable.
Yeah, I see what you mean. But it costs us only the patching and after
that we win from not needing for fetch boot_cpu_data anymore on the APs
coming up.
Not a panties-dropper speedup but I still think it is worth the trouble.
> That being said, I have no meaningful objection to this patch.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web