Messages in this thread | | | Date | Tue, 3 Oct 2023 21:43:51 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC PATCH 0/4] x86/percpu: Use segment qualifiers |
| |
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Tue, 3 Oct 2023 at 06:38, Ingo Molnar <mingo@kernel.org> wrote: > > > > So I don't think it's a good idea to restrict it to the devel GCC version > > only, the cross-section of devel-GCC and devel-kernel reduces testing > > coverage to near-zero in practice ... > > In fact, while the clang failure was arguably worse from a code > generation standpoint (as in "it didn't generate any code AT ALL"), it > was actually better from a kernel standpoint: I'd *much* rather have a > compile-time failure than bad code generation when it's a particular > issue that we can avoid by just not doing it. > > IOW, *if* this is the only actual issue with named address spaces, > then I'd much rather have a compiler that says "don't do that" over a > compiler that silently generates absolutely horrendous code. > > That is not unlike my "I'd rather get a link time error from trying to > do a 64-by-64 divide on x86-32, than have the compiler actually > generate that horrendously expensive operation". There's a reason we > have "do_div64()" to do 64-by-32 divides, because that's usually what > you actually want. > > We should not be doing big structure copies from or to the percpu > area, so clang then failing with an admittedly horrendous error > message is not a bad thing. > > And again - my worry really isn't this "copy a percpu structure" > issue. It's literally just that I feel this doesn't have a lot of > coverage.
I share all those concerns.
So we could do this: we let it live in -tip for a cycle, in a separate branch, and observe what happens - it gets picked up by -next on a daily basis and most x86 developers test it. It won't be merged by other branches in -tip, it won't be pulled by others or relied on. If it conflicts with other bits we rebase it cleanly, no questions asked.
While -next test coverage is still limited in many ways, it's also certainly not zero.
If it's problem-free for a cycle I'll offer it up to you as an RFC pull, summarizing our experience with it. (Should it ever get to that point.)
That's the best I think we can do - and worst-case we'll turn it off again and go curse flaky compiler features. Will be easy to turn off if it's compiler version triggered anyway.
Thanks,
Ingo
| |