[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whNVf+YghEH4JNjp99NzG5+M7CQrLK42VNKnDydBG4ovA@mail.gmail.com>
Date: Thu, 12 Oct 2023 10:16:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nadav Amit <namit@...are.com>
Cc: Uros Bizjak <ubizjak@...il.com>,
"the arch/x86 maintainers" <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...nel.org>,
Brian Gerst <brgerst@...il.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()
On Thu, 12 Oct 2023 at 08:19, Nadav Amit <namit@...are.com> wrote:
>
> +/*
> + * Hold a constant alias for current_task, which would allow to avoid caching of
> + * current task.
> + *
> + * We must mark const_current_task with the segment qualifiers, as otherwise gcc
> + * would do redundant reads of const_current_task.
> + */
> +DECLARE_PER_CPU(struct pcpu_hot const __percpu_seg_override, const_pcpu_hot);
Hmm. The only things I'm not super-happy about with your patch is
(a) it looks like this depends on the alias analysis knowing that the
__seg_gs isn't affected by normal memory ops. That implies that this
will not work well with compiler versions that don't do that?
(b) This declaration doesn't match the other one. So now there are
two *different* declarations for const_pcpu_hot, which I really don't
like.
That second one would seem to be trivial to just fix (or maybe not,
and you do it that way for some horrible reason).
The first one sounds bad to me - basically making the *reason* for
this patch go away - but maybe the compilers that don't support
address spaces are so rare that we can ignore it.
Linus
Powered by blists - more mailing lists