On Sun, Aug 30 2020 at 12:13, Linus Torvalds wrote:
> On Sun, Aug 30, 2020 at 11:04 AM Thomas Gleixner wrote:
>>
>>The historical inconsistent for_each_cpu() behaviour of
>>ignoring the cpumask and unconditionally claiming that CPU0 is in the
>>mask struck again. Sigh.
>
> I guess we c
The pull request you sent on Sun, 30 Aug 2020 18:03:39 -:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-urgent-2020-08-30
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dcc5c6f013d841e9ae74d527d312d512dfc2e2f0
Thank you!
--
Deet-doot-dot, I
On Sun, Aug 30, 2020 at 11:04 AM Thomas Gleixner wrote:
>
>The historical inconsistent for_each_cpu() behaviour of
>ignoring the cpumask and unconditionally claiming that CPU0 is in the
>mask struck again. Sigh.
I guess we could remove the UP optimizations these days. It's not like
th
Linus,
please pull the latest x86/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-2020-08-30
up to: 784a0830377d: genirq/matrix: Deal with the sillyness of for_each_cpu()
on UP
Three interrupt related fixes for X86:
- Move disabling of the local
On Sun, Aug 23, 2020 at 3:35 PM Linus Torvalds
wrote:
>
> On Sun, Aug 23, 2020 at 3:27 PM Andy Lutomirski wrote:
> >
> > Every interrupt is going to load the CS and SS descriptor cache lines.
>
> Yeah, but this isn't even sharing the same GDT cache line. Those two
> are at least in the same cache
On Sun, Aug 23, 2020 at 3:27 PM Andy Lutomirski wrote:
>
> Every interrupt is going to load the CS and SS descriptor cache lines.
Yeah, but this isn't even sharing the same GDT cache line. Those two
are at least in the same cacheline, and hey, that is forced upon us by
the architecture, so we don
On Sun, Aug 23, 2020 at 3:01 PM Thomas Gleixner wrote:
>
> > And I don't think we need the GDT for anything else normally, so it's
> > not even going to be cached.
>
> Who cares, really?
>
> It's pretty irrelevant because the main source of horrors are in having
> to run through _ALL_ registered N
On Sun, Aug 23, 2020 at 11:29 AM Linus Torvalds
wrote:
>
> On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote:
> >
> > Remove the RDPID optimization, which is not even
> > backed by numbers from the paranoid entry path instead.
>
> Ugh, that's sad. I'd expect the LSL to be quite a bit slower t
On Sun, Aug 23 2020 at 11:29, Linus Torvalds wrote:
> On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote:
>>
>> Remove the RDPID optimization, which is not even
>> backed by numbers from the paranoid entry path instead.
>
> Ugh, that's sad. I'd expect the LSL to be quite a bit slower than the
>
The pull request you sent on Sun, 23 Aug 2020 08:25:37 -:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-urgent-2020-08-23
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/550c2129d93d5eb198835ac83c05ef672e8c491c
Thank you!
--
Deet-doot-dot, I
On Sun, Aug 23, 2020 at 1:26 AM Thomas Gleixner wrote:
>
> Remove the RDPID optimization, which is not even
> backed by numbers from the paranoid entry path instead.
Ugh, that's sad. I'd expect the LSL to be quite a bit slower than the
RDPID on raw hardware, since LSL has to go out to the GDT.
A
Linus,
please pull the latest x86/urgent branch from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-2020-08-23
up to: 6a3ea3e68b8a: x86/entry/64: Do not use RDPID in paranoid entry to
accomodate KVM
A single fix for x86 which removes the RDPID usage from the parano
12 matches
Mail list logo
