Re: [PATCH v2] x86/mm/tlb: Remove flush_tlb_info from the stack
From: Nadav Amit
Date: Fri Apr 26 2019 - 04:37:46 EST
> On Apr 26, 2019, at 12:53 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>
> On Thu, Apr 25, 2019 at 09:20:24PM +0000, Nadav Amit wrote:
>
>>> I think that's a bug and PeterZ is fixing those.
>>
>> This would be quite surprising.
>
> I need to get back to that percpu series .... :/
>
>> Even atomic_dec() does not imply a compilers
>> barrier. I think I should leave it as is for now, and let Peter change it
>> later if he decides to do so. Let me know if you disagree.
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.kernel.org%2Fr%2F20190424124421.808471451%40infradead.org&data=02%7C01%7Cnamit%40vmware.com%7Cc58182519059466b21e708d6ca1c5964%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636918620470835044&sdata=PpijqcCDBmWdVcoPNtx6oiNJsXj%2FED1z5k%2BdUeCifJM%3D&reserved=0
Interesting! (and thanks for the reference). Well, I said it would be quite
surprising, and I see you wrote the same thing in the patch ;-)
But correct me if Iâm wrong - it does sound as if you âscrewâ all the uses
of atomic_inc() and atomic_dec() (~4000 instances) for the fewer uses of
smp_mb__after_atomic() and smp_mb__before_atomic() (~400 instances).
Do you intend to at least introduce a variant of atomic_inc() without a
memory barrier?