Re: in_irq_or_nmi() and RFC patch

On Mon, Apr 03, 2017 at 01:05:06PM +0100, Mel Gorman wrote: > > Started performance benchmarking: > > 163 cycles = current state > > 183 cycles = with BH disable + in_irq > > 218 cycles = with BH disable + in_irq + irqs_disabled > > > > Thus, the performance numbers unfortunately looks bad,

Re: in_irq_or_nmi() and RFC patch

On Mon, Apr 03, 2017 at 01:05:06PM +0100, Mel Gorman wrote: > > Started performance benchmarking: > > 163 cycles = current state > > 183 cycles = with BH disable + in_irq > > 218 cycles = with BH disable + in_irq + irqs_disabled > > > > Thus, the performance numbers unfortunately looks bad,

Re: in_irq_or_nmi() and RFC patch

On Thu, Mar 30, 2017 at 05:07:08PM +0200, Jesper Dangaard Brouer wrote: > On Thu, 30 Mar 2017 14:04:36 +0100 > Mel Gorman wrote: > > > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > > > Regardless or using in_irq() (or in combi with

Re: in_irq_or_nmi() and RFC patch

On Thu, Mar 30, 2017 at 05:07:08PM +0200, Jesper Dangaard Brouer wrote: > On Thu, 30 Mar 2017 14:04:36 +0100 > Mel Gorman wrote: > > > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > > > Regardless or using in_irq() (or in combi with in_nmi()) I get the > > > >

Re: in_irq_or_nmi() and RFC patch

On Thu, 30 Mar 2017 14:04:36 +0100 Mel Gorman wrote: > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > > Regardless or using in_irq() (or in combi with in_nmi()) I get the > > > following warning below: > > > > > > [0.00] Kernel

Re: in_irq_or_nmi() and RFC patch

On Thu, 30 Mar 2017 14:04:36 +0100 Mel Gorman wrote: > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > > Regardless or using in_irq() (or in combi with in_nmi()) I get the > > > following warning below: > > > > > > [0.00] Kernel command line: > > >

Re: in_irq_or_nmi() and RFC patch

On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > Regardless or using in_irq() (or in combi with in_nmi()) I get the > > following warning below: > > > > [0.00] Kernel command line: > > BOOT_IMAGE=/vmlinuz-4.11.0-rc3-net-next-page-alloc-softirq+ > >

Re: in_irq_or_nmi() and RFC patch

On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > Regardless or using in_irq() (or in combi with in_nmi()) I get the > > following warning below: > > > > [0.00] Kernel command line: > > BOOT_IMAGE=/vmlinuz-4.11.0-rc3-net-next-page-alloc-softirq+ > >

Re: in_irq_or_nmi() and RFC patch

On Thu, 30 Mar 2017 09:35:02 +0200 Peter Zijlstra wrote: > On Thu, Mar 30, 2017 at 09:12:23AM +0200, Jesper Dangaard Brouer wrote: > > On Thu, 30 Mar 2017 08:49:58 +0200 > > Peter Zijlstra wrote: > > > > > On Wed, Mar 29, 2017 at 09:44:41PM +0200,

Re: in_irq_or_nmi() and RFC patch

On Thu, 30 Mar 2017 09:35:02 +0200 Peter Zijlstra wrote: > On Thu, Mar 30, 2017 at 09:12:23AM +0200, Jesper Dangaard Brouer wrote: > > On Thu, 30 Mar 2017 08:49:58 +0200 > > Peter Zijlstra wrote: > > > > > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > > > @@

Re: in_irq_or_nmi() and RFC patch

On Thu, Mar 30, 2017 at 09:12:23AM +0200, Jesper Dangaard Brouer wrote: > On Thu, 30 Mar 2017 08:49:58 +0200 > Peter Zijlstra wrote: > > > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct

Re: in_irq_or_nmi() and RFC patch

On Thu, Mar 30, 2017 at 09:12:23AM +0200, Jesper Dangaard Brouer wrote: > On Thu, 30 Mar 2017 08:49:58 +0200 > Peter Zijlstra wrote: > > > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct page *page, bool > > >

Re: in_irq_or_nmi() and RFC patch

On Thu, 30 Mar 2017 08:49:58 +0200 Peter Zijlstra wrote: > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct page *page, bool cold) > > unsigned long pfn = page_to_pfn(page); > > int

Re: in_irq_or_nmi() and RFC patch

On Thu, 30 Mar 2017 08:49:58 +0200 Peter Zijlstra wrote: > On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct page *page, bool cold) > > unsigned long pfn = page_to_pfn(page); > > int migratetype; > > > > -

Re: in_irq_or_nmi() and RFC patch

On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct page *page, bool cold) > unsigned long pfn = page_to_pfn(page); > int migratetype; > > - if (in_interrupt()) { > + /* > + * Exclude (hard) IRQ

Re: in_irq_or_nmi() and RFC patch

On Wed, Mar 29, 2017 at 09:44:41PM +0200, Jesper Dangaard Brouer wrote: > @@ -2481,7 +2481,11 @@ void free_hot_cold_page(struct page *page, bool cold) > unsigned long pfn = page_to_pfn(page); > int migratetype; > > - if (in_interrupt()) { > + /* > + * Exclude (hard) IRQ

Re: in_irq_or_nmi() and RFC patch

fall-through using the normal buddy allocator path). > > > > > > Any in_nmi() code arriving at the allocator is broken. No need to fix > > > the allocator. > > > > That's demonstrably true. You can't grab a spinlock in NMI code and > > the first thing

Re: in_irq_or_nmi() and RFC patch

gt; Any in_nmi() code arriving at the allocator is broken. No need to fix > > > the allocator. > > > > That's demonstrably true. You can't grab a spinlock in NMI code and > > the first thing that happens if this in_irq_or_nmi() check fails is ... > >

Re: in_irq_or_nmi()

ude NMI and HARDIRQ from > > > using the per-cpu-pages (pcp) lists "order-0 cache" (they will > > > fall-through using the normal buddy allocator path). > > > > Any in_nmi() code arriving at the allocator is broken. No need to fix > > the allocator. > &

Re: in_irq_or_nmi()

cp) lists "order-0 cache" (they will > > > fall-through using the normal buddy allocator path). > > > > Any in_nmi() code arriving at the allocator is broken. No need to fix > > the allocator. > > That's demonstrably true. You can't grab a spinl

Re: in_irq_or_nmi()

h using the normal buddy allocator path). > > Any in_nmi() code arriving at the allocator is broken. No need to fix > the allocator. That's demonstrably true. You can't grab a spinlock in NMI code and the first thing that happens if this in_irq_or_nmi() check fails is ... spin_lock_irqsav

Re: in_irq_or_nmi()

> > Any in_nmi() code arriving at the allocator is broken. No need to fix > the allocator. That's demonstrably true. You can't grab a spinlock in NMI code and the first thing that happens if this in_irq_or_nmi() check fails is ... spin_lock_irqsave(>lock, flags); so this patch

Re: in_irq_or_nmi()

>│ ↓ jne1e4 > > > > > > > > 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). > > > > > >

Re: in_irq_or_nmi()

│ ↓ jne1e4 > > > > > > > > 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

Re: in_irq_or_nmi()

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 > &

Re: in_irq_or_nmi()

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 mig

Re: in_irq_or_nmi()

(): > > 1.25 │ test $0x1f,%eax > >│ ↓ jne1e4 > > > > 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

Re: in_irq_or_nmi()

(): > > 1.25 │ test $0x1f,%eax > >│ ↓ jne1e4 > > > > 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

in_irq_or_nmi()

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 doi

in_irq_or_nmi()

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 doi