All of lore.kernel.org
 help / color / mirror / Atom feed
From: zhong jiang <zhongjiang@huawei.com>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: akpm@linux-foundation.org, vbabka@suse.cz, linux-mm@kvack.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>, Rik van Riel <riel@redhat.com>,
	hillf.zj@alibaba-inc.com, tglx@linutronix.de, brouer@redhat.com
Subject: Re: [PATCH] mm, page_alloc: fix the duplicate save/ressave irq
Date: Mon, 13 Mar 2017 22:51:36 +0800	[thread overview]
Message-ID: <58C6B1F8.90702@huawei.com> (raw)
In-Reply-To: <20170313142636.ghschfm2sff7j7oh@techsingularity.net>

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>

  reply	other threads:[~2017-03-13 14:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-03-14 12:06       ` zhong jiang
2017-03-14 13:51         ` Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58C6B1F8.90702@huawei.com \
    --to=zhongjiang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=brouer@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=hillf.zj@alibaba-inc.com \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=riel@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.