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@xxxxxxxxxx>
> >>
> >> 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@xxxxxxxxxx>
> > 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@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
