[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1702081550440.3536@nanos>
Date: Wed, 8 Feb 2017 15:56:22 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Mel Gorman <mgorman@...hsingularity.net>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Michal Hocko <mhocko@...nel.org>,
Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] mm, page_alloc: only use per-cpu allocator for irq-safe
requests -fix
On Wed, 8 Feb 2017, Mel Gorman wrote:
> preempt_enable_no_resched() was used based on review feedback that had no
> strong objection at the time. It avoided introducing a preemption point
> where one didn't exist before which was marginal at best.
Actually local_irq_enable() _IS_ a preemption point, indirect but still:
local_irq_disable()
....
--> HW interrupt is raised
....
local_irq_enable()
handle_irq()
set_need_resched()
ret_from_irq()
preempt()
while with preempt_disable that looks like this:
preempt_disable()
....
--> HW interrupt is raised
handle_irq()
set_need_resched()
ret_from_irq()
....
preempt_enable()
preempt()
Now if you use preempt_enable_no_resched() then you miss the preemption and
depending on the actual code path you might run something which takes ages
without hitting a preemption point after that.
It's not only a problem for RT. It's also in mainline a violation of the
preemption mechanism.
Thanks,
tglx
Powered by blists - more mailing lists