Messages in this thread Patch in this message | | | Date | Tue, 27 Oct 2009 13:09:24 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 2/3] page allocator: Do not allow interrupts to use ALLOC_HARDER |
| |
On Tue, 27 Oct 2009 13:40:32 +0000 Mel Gorman <mel@csn.ul.ie> wrote:
> Commit 341ce06f69abfafa31b9468410a13dbd60e2b237 altered watermark logic > slightly by allowing rt_tasks that are handling an interrupt to set > ALLOC_HARDER. This patch brings the watermark logic more in line with > 2.6.30. > > [rientjes@google.com: Spotted the problem] > Signed-off-by: Mel Gorman <mel@csn.ul.ie> > Reviewed-by: Pekka Enberg <penberg@cs.helsinki.fi> > Reviewed-by: Rik van Riel <riel@redhat.com> > Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> > --- > mm/page_alloc.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index dfa4362..7f2aa3e 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1769,7 +1769,7 @@ gfp_to_alloc_flags(gfp_t gfp_mask) > * See also cpuset_zone_allowed() comment in kernel/cpuset.c. > */ > alloc_flags &= ~ALLOC_CPUSET; > - } else if (unlikely(rt_task(p))) > + } else if (unlikely(rt_task(p)) && !in_interrupt()) > alloc_flags |= ALLOC_HARDER; > > if (likely(!(gfp_mask & __GFP_NOMEMALLOC))) {
What are the runtime-observeable effects of this change?
The description is a bit waffly-sounding for a -stable backportable thing, IMO. What reason do the -stable maintainers and users have to believe that this patch is needed, and an improvement?
| |