On Wed, 29 Mar 2017 10:12:19 +0200 Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Mon, Mar 27, 2017 at 09:58:17AM -0700, Matthew Wilcox wrote: > > On Mon, Mar 27, 2017 at 05:15:00PM +0200, Jesper Dangaard Brouer wrote: > > > And I also verified it worked: > > > > > > 0.63 │ mov __preempt_count,%eax > > > │ free_hot_cold_page(): > > > 1.25 │ test $0x1f0000,%eax > > > │ ↓ jne 1e4 > > > > > > And this simplification also made the compiler change this into a > > > unlikely branch, which is a micro-optimization (that I will leave up to > > > the compiler). > > > > Excellent! That said, I think we should define in_irq_or_nmi() in > > preempt.h, rather than hiding it in the memory allocator. And since we're > > doing that, we might as well make it look like the other definitions: > > > > diff --git a/include/linux/preempt.h b/include/linux/preempt.h > > index 7eeceac52dea..af98c29abd9d 100644 > > --- a/include/linux/preempt.h > > +++ b/include/linux/preempt.h > > @@ -81,6 +81,7 @@ > > #define in_interrupt() (irq_count()) > > #define in_serving_softirq() (softirq_count() & SOFTIRQ_OFFSET) > > #define in_nmi() (preempt_count() & NMI_MASK) > > +#define in_irq_or_nmi() (preempt_count() & (HARDIRQ_MASK | NMI_MASK)) > > #define in_task() (!(preempt_count() & \ > > (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET))) > > > > No, that's horrible. Also, wth is this about? A memory allocator that > needs in_nmi()? That sounds beyond broken. It is the other way around. We want to exclude NMI and HARDIRQ from using the per-cpu-pages (pcp) lists "order-0 cache" (they will fall-through using the normal buddy allocator path). -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href
