linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
@ 2017-03-13  8:02 zhongjiang
  2017-03-13  8:31 ` Vlastimil Babka
  2017-03-13 11:19 ` Mel Gorman
  0 siblings, 2 replies; 10+ messages in thread
From: zhongjiang @ 2017-03-13  8:02 UTC (permalink / raw)
  To: mgorman, akpm; +Cc: vbabka, linux-mm

From: zhong jiang <zhongjiang@huawei.com>

when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
the IRQ context. but drain_pages_zone fails to clear away the irq. because
preempt_disable have take effect. so it safely remove the code.

Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
---
 mm/page_alloc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 05c3956..7b16095 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2294,11 +2294,9 @@ void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp)
  */
 static void drain_pages_zone(unsigned int cpu, struct zone *zone)
 {
-	unsigned long flags;
 	struct per_cpu_pageset *pset;
 	struct per_cpu_pages *pcp;
 
-	local_irq_save(flags);
 	pset = per_cpu_ptr(zone->pageset, cpu);
 
 	pcp = &pset->pcp;
@@ -2306,7 +2304,6 @@ static void drain_pages_zone(unsigned int cpu, struct zone *zone)
 		free_pcppages_bulk(zone, pcp->count, pcp);
 		pcp->count = 0;
 	}
-	local_irq_restore(flags);
 }
 
 /*
-- 
1.8.3.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13  8:02 [PATCH] mm, page_alloc: fix the duplicate save/ressave irq zhongjiang
@ 2017-03-13  8:31 ` Vlastimil Babka
  2017-03-13 10:08   ` Vlastimil Babka
  2017-03-13 11:19 ` Mel Gorman
  1 sibling, 1 reply; 10+ messages in thread
From: Vlastimil Babka @ 2017-03-13  8:31 UTC (permalink / raw)
  To: zhongjiang, mgorman, akpm; +Cc: linux-mm

On 03/13/2017 09:02 AM, zhongjiang wrote:
> From: zhong jiang <zhongjiang@huawei.com>
> 
> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
> the IRQ context. but drain_pages_zone fails to clear away the irq. because
> preempt_disable have take effect. so it safely remove the code.
> 
> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
>  mm/page_alloc.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 05c3956..7b16095 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2294,11 +2294,9 @@ void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp)
>   */
>  static void drain_pages_zone(unsigned int cpu, struct zone *zone)
>  {
> -	unsigned long flags;
>  	struct per_cpu_pageset *pset;
>  	struct per_cpu_pages *pcp;
>  
> -	local_irq_save(flags);
>  	pset = per_cpu_ptr(zone->pageset, cpu);

NAK. we have to make sure that pset corresponds to the cpu we are
running on.

>  
>  	pcp = &pset->pcp;
> @@ -2306,7 +2304,6 @@ static void drain_pages_zone(unsigned int cpu, struct zone *zone)
>  		free_pcppages_bulk(zone, pcp->count, pcp);
>  		pcp->count = 0;
>  	}
> -	local_irq_restore(flags);
>  }
>  
>  /*
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13  8:31 ` Vlastimil Babka
@ 2017-03-13 10:08   ` Vlastimil Babka
  2017-03-13 10:53     ` zhong jiang
  0 siblings, 1 reply; 10+ messages in thread
From: Vlastimil Babka @ 2017-03-13 10:08 UTC (permalink / raw)
  To: zhongjiang, mgorman, akpm; +Cc: linux-mm

On 03/13/2017 09:31 AM, Vlastimil Babka wrote:
> On 03/13/2017 09:02 AM, zhongjiang wrote:
>> From: zhong jiang <zhongjiang@huawei.com>
>>
>> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
>> the IRQ context. but drain_pages_zone fails to clear away the irq. because
>> preempt_disable have take effect. so it safely remove the code.
>>
>> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>>  mm/page_alloc.c | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 05c3956..7b16095 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -2294,11 +2294,9 @@ void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp)
>>   */
>>  static void drain_pages_zone(unsigned int cpu, struct zone *zone)
>>  {
>> -	unsigned long flags;
>>  	struct per_cpu_pageset *pset;
>>  	struct per_cpu_pages *pcp;
>>  
>> -	local_irq_save(flags);
>>  	pset = per_cpu_ptr(zone->pageset, cpu);
> 
> NAK. we have to make sure that pset corresponds to the cpu we are
> running on.

Sorry, I was thinking about other callers, such as drain_local_pages(),
but seems like all have the cpu pinned prerequisity.

But do we know that there can't be an interrupt updating pcp->count
between the moment we read it and we call free_pcppages_bulk? This
should be also discussed in the changelog. Also the "Fixes:" tag is not
necessary for a performance optimization.

> 
>>  
>>  	pcp = &pset->pcp;
>> @@ -2306,7 +2304,6 @@ static void drain_pages_zone(unsigned int cpu, struct zone *zone)
>>  		free_pcppages_bulk(zone, pcp->count, pcp);
>>  		pcp->count = 0;
>>  	}
>> -	local_irq_restore(flags);
>>  }
>>  
>>  /*
>>
> 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13 10:08   ` Vlastimil Babka
@ 2017-03-13 10:53     ` zhong jiang
  0 siblings, 0 replies; 10+ messages in thread
From: zhong jiang @ 2017-03-13 10:53 UTC (permalink / raw)
  To: Vlastimil Babka; +Cc: mgorman, akpm, linux-mm

On 2017/3/13 18:08, Vlastimil Babka wrote:
> On 03/13/2017 09:31 AM, Vlastimil Babka wrote:
>> On 03/13/2017 09:02 AM, zhongjiang wrote:
>>> From: zhong jiang <zhongjiang@huawei.com>
>>>
>>> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>>> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
>>> the IRQ context. but drain_pages_zone fails to clear away the irq. because
>>> preempt_disable have take effect. so it safely remove the code.
>>>
>>> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>> ---
>>>  mm/page_alloc.c | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index 05c3956..7b16095 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -2294,11 +2294,9 @@ void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp)
>>>   */
>>>  static void drain_pages_zone(unsigned int cpu, struct zone *zone)
>>>  {
>>> -	unsigned long flags;
>>>  	struct per_cpu_pageset *pset;
>>>  	struct per_cpu_pages *pcp;
>>>  
>>> -	local_irq_save(flags);
>>>  	pset = per_cpu_ptr(zone->pageset, cpu);
>> NAK. we have to make sure that pset corresponds to the cpu we are
>> running on.
> Sorry, I was thinking about other callers, such as drain_local_pages(),
> but seems like all have the cpu pinned prerequisity.
>
> But do we know that there can't be an interrupt updating pcp->count
> between the moment we read it and we call free_pcppages_bulk? This
> should be also discussed in the changelog. Also the "Fixes:" tag is not
> necessary for a performance optimization.
 The title is misunderstanding. it is just for performence optimization.
 I will resent it in v2.

 Thanks
 zhongjiang
>>>  
>>>  	pcp = &pset->pcp;
>>> @@ -2306,7 +2304,6 @@ static void drain_pages_zone(unsigned int cpu, struct zone *zone)
>>>  		free_pcppages_bulk(zone, pcp->count, pcp);
>>>  		pcp->count = 0;
>>>  	}
>>> -	local_irq_restore(flags);
>>>  }
>>>  
>>>  /*
>>>
>
> .
>


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13  8:02 [PATCH] mm, page_alloc: fix the duplicate save/ressave irq zhongjiang
  2017-03-13  8:31 ` Vlastimil Babka
@ 2017-03-13 11:19 ` Mel Gorman
  2017-03-13 13:59   ` zhong jiang
  1 sibling, 1 reply; 10+ messages in thread
From: Mel Gorman @ 2017-03-13 11:19 UTC (permalink / raw)
  To: zhongjiang; +Cc: akpm, vbabka, linux-mm

On Mon, Mar 13, 2017 at 04:02:54PM +0800, zhongjiang wrote:
> From: zhong jiang <zhongjiang@huawei.com>
> 
> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
> the IRQ context. but drain_pages_zone fails to clear away the irq. because
> preempt_disable have take effect. so it safely remove the code.
> 
> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>

It's not really a fix but is this even measurable?

The reason the IRQ saving was preserved was for callers that are removing
the CPU where it's not 100% clear if the CPU is protected from IPIs at
the time the pcpu drain takes place. It may be ok but the changelog
should include an indication that it has been considered and is known to
be fine versus CPU hotplug.

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13 11:19 ` Mel Gorman
@ 2017-03-13 13:59   ` zhong jiang
  2017-03-13 14:26     ` Mel Gorman
  0 siblings, 1 reply; 10+ messages in thread
From: zhong jiang @ 2017-03-13 13:59 UTC (permalink / raw)
  To: Mel Gorman; +Cc: akpm, vbabka, linux-mm

On 2017/3/13 19:19, Mel Gorman wrote:
> On Mon, Mar 13, 2017 at 04:02:54PM +0800, zhongjiang wrote:
>> From: zhong jiang <zhongjiang@huawei.com>
>>
>> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
>> the IRQ context. but drain_pages_zone fails to clear away the irq. because
>> preempt_disable have take effect. so it safely remove the code.
>>
>> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> It's not really a fix but is this even measurable?
>
> The reason the IRQ saving was preserved was for callers that are removing
> the CPU where it's not 100% clear if the CPU is protected from IPIs at
> the time the pcpu drain takes place. It may be ok but the changelog
> should include an indication that it has been considered and is known to
> be fine versus CPU hotplug.
>
you mean the removing cpu maybe  handle the IRQ, it will result in the incorrect pcpu->count ?

but I don't sure that dying cpu remain handle the IRQ.

Thanks
zhongjinag

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13 13:59   ` zhong jiang
@ 2017-03-13 14:26     ` Mel Gorman
  2017-03-13 14:51       ` zhong jiang
  2017-03-14 12:06       ` zhong jiang
  0 siblings, 2 replies; 10+ messages in thread
From: Mel Gorman @ 2017-03-13 14:26 UTC (permalink / raw)
  To: zhong jiang; +Cc: akpm, vbabka, linux-mm

On Mon, Mar 13, 2017 at 09:59:33PM +0800, zhong jiang wrote:
> On 2017/3/13 19:19, Mel Gorman wrote:
> > On Mon, Mar 13, 2017 at 04:02:54PM +0800, zhongjiang wrote:
> >> From: zhong jiang <zhongjiang@huawei.com>
> >>
> >> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
> >> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
> >> the IRQ context. but drain_pages_zone fails to clear away the irq. because
> >> preempt_disable have take effect. so it safely remove the code.
> >>
> >> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
> >> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> > It's not really a fix but is this even measurable?
> >
> > The reason the IRQ saving was preserved was for callers that are removing
> > the CPU where it's not 100% clear if the CPU is protected from IPIs at
> > the time the pcpu drain takes place. It may be ok but the changelog
> > should include an indication that it has been considered and is known to
> > be fine versus CPU hotplug.
> >
> you mean the removing cpu maybe  handle the IRQ, it will result in the incorrect pcpu->count ?
> 

Yes, if it hasn't had interrupts disabled yet at the time of the drain.
I didn't check, it probably is called from a context that disables
interrupts but the fact you're not sure makes me automatically wary of
the patch particularly given how little difference it makes for the common
case where direct reclaim failed triggering a drain.

> but I don't sure that dying cpu remain handle the IRQ.
> 

You'd need to be certain to justify the patch.

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13 14:26     ` Mel Gorman
@ 2017-03-13 14:51       ` zhong jiang
  2017-03-14 12:06       ` zhong jiang
  1 sibling, 0 replies; 10+ messages in thread
From: zhong jiang @ 2017-03-13 14:51 UTC (permalink / raw)
  To: Mel Gorman
  Cc: akpm, vbabka, linux-mm, Johannes Weiner, Michal Hocko,
	Rik van Riel, hillf.zj, tglx, brouer

On 2017/3/13 22:26, Mel Gorman wrote:
> On Mon, Mar 13, 2017 at 09:59:33PM +0800, zhong jiang wrote:
>> On 2017/3/13 19:19, Mel Gorman wrote:
>>> On Mon, Mar 13, 2017 at 04:02:54PM +0800, zhongjiang wrote:
>>>> From: zhong jiang <zhongjiang@huawei.com>
>>>>
>>>> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>>>> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
>>>> the IRQ context. but drain_pages_zone fails to clear away the irq. because
>>>> preempt_disable have take effect. so it safely remove the code.
>>>>
>>>> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>> It's not really a fix but is this even measurable?
>>>
>>> The reason the IRQ saving was preserved was for callers that are removing
>>> the CPU where it's not 100% clear if the CPU is protected from IPIs at
>>> the time the pcpu drain takes place. It may be ok but the changelog
>>> should include an indication that it has been considered and is known to
>>> be fine versus CPU hotplug.
>>>
>> you mean the removing cpu maybe  handle the IRQ, it will result in the incorrect pcpu->count ?
>>
> Yes, if it hasn't had interrupts disabled yet at the time of the drain.
> I didn't check, it probably is called from a context that disables
> interrupts but the fact you're not sure makes me automatically wary of
> the patch particularly given how little difference it makes for the common
> case where direct reclaim failed triggering a drain.
  Ok, I will test the benefits or not when direct reclaim failed and trigger a drain.  
>> but I don't sure that dying cpu remain handle the IRQ.
>>
> You'd need to be certain to justify the patch.
>
 Truely , Still  undecided it i rational at least theretically.  

Thanks
zhongjiang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-13 14:26     ` Mel Gorman
  2017-03-13 14:51       ` zhong jiang
@ 2017-03-14 12:06       ` zhong jiang
  2017-03-14 13:51         ` Mel Gorman
  1 sibling, 1 reply; 10+ messages in thread
From: zhong jiang @ 2017-03-14 12:06 UTC (permalink / raw)
  To: Mel Gorman; +Cc: akpm, vbabka, linux-mm

On 2017/3/13 22:26, Mel Gorman wrote:
> On Mon, Mar 13, 2017 at 09:59:33PM +0800, zhong jiang wrote:
>> On 2017/3/13 19:19, Mel Gorman wrote:
>>> On Mon, Mar 13, 2017 at 04:02:54PM +0800, zhongjiang wrote:
>>>> From: zhong jiang <zhongjiang@huawei.com>
>>>>
>>>> when commit 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>>>> introduced to the mainline, free_pcppages_bulk irq_save/resave to protect
>>>> the IRQ context. but drain_pages_zone fails to clear away the irq. because
>>>> preempt_disable have take effect. so it safely remove the code.
>>>>
>>>> Fixes: 374ad05ab64d ("mm, page_alloc: only use per-cpu allocator for irq-safe requests")
>>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>> It's not really a fix but is this even measurable?
>>>
>>> The reason the IRQ saving was preserved was for callers that are removing
>>> the CPU where it's not 100% clear if the CPU is protected from IPIs at
>>> the time the pcpu drain takes place. It may be ok but the changelog
>>> should include an indication that it has been considered and is known to
>>> be fine versus CPU hotplug.
>>>
>> you mean the removing cpu maybe  handle the IRQ, it will result in the incorrect pcpu->count ?
>>
> Yes, if it hasn't had interrupts disabled yet at the time of the drain.
> I didn't check, it probably is called from a context that disables
> interrupts but the fact you're not sure makes me automatically wary of
> the patch particularly given how little difference it makes for the common
> case where direct reclaim failed triggering a drain.
>
>> but I don't sure that dying cpu remain handle the IRQ.
>>
> You'd need to be certain to justify the patch.
>
 Hi,  Mel
   
    by code review,  I see the cpu hotplug will only register the notfier to callback the function without
  interrupt come.  is it right ??

Thanks
zhongjiang

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
  2017-03-14 12:06       ` zhong jiang
@ 2017-03-14 13:51         ` Mel Gorman
  0 siblings, 0 replies; 10+ messages in thread
From: Mel Gorman @ 2017-03-14 13:51 UTC (permalink / raw)
  To: zhong jiang; +Cc: akpm, vbabka, linux-mm

On Tue, Mar 14, 2017 at 08:06:34PM +0800, zhong jiang wrote:
> >> you mean the removing cpu maybe  handle the IRQ, it will result in the incorrect pcpu->count ?
> >>
> > Yes, if it hasn't had interrupts disabled yet at the time of the drain.
> > I didn't check, it probably is called from a context that disables
> > interrupts but the fact you're not sure makes me automatically wary of
> > the patch particularly given how little difference it makes for the common
> > case where direct reclaim failed triggering a drain.
> >
> >> but I don't sure that dying cpu remain handle the IRQ.
> >>
> > You'd need to be certain to justify the patch.
> >
>  Hi,  Mel
>    
>     by code review,  I see the cpu hotplug will only register the notfier to callback the function without
>   interrupt come.  is it right ??
> 

That sentence is impossible to parse meaningfully. The patch was
posted without verifying it made any performance difference (it almost
certainly won't) and without checking all the callers are actually safe
(which you're still not sure of).

Consider the patch NAK'd on both grounds (marginal, if any improvement
with no checking that the patch is safe).

-- 
Mel Gorman
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-03-14 13:51 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-13  8:02 [PATCH] mm, page_alloc: fix the duplicate save/ressave irq zhongjiang
2017-03-13  8:31 ` Vlastimil Babka
2017-03-13 10:08   ` Vlastimil Babka
2017-03-13 10:53     ` zhong jiang
2017-03-13 11:19 ` Mel Gorman
2017-03-13 13:59   ` zhong jiang
2017-03-13 14:26     ` Mel Gorman
2017-03-13 14:51       ` zhong jiang
2017-03-14 12:06       ` zhong jiang
2017-03-14 13:51         ` Mel Gorman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).