Messages in this thread | | | From | Nadav Amit <> | Subject | Re: [PATCH v2] x86/mm/tlb: Remove flush_tlb_info from the stack | Date | Fri, 26 Apr 2019 08:37:37 +0000 |
| |
> On Apr 26, 2019, at 12:53 AM, Peter Zijlstra <peterz@infradead.org> 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? | |