[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091022125120.GN11778@csn.ul.ie>
Date: Thu, 22 Oct 2009 13:51:20 +0100
From: Mel Gorman <mel@....ul.ie>
To: Pekka Enberg <penberg@...helsinki.fi>
Cc: David Rientjes <rientjes@...gle.com>,
Jiri Kosina <jkosina@...e.cz>,
Stephan von Krawczynski <skraw@...net.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Frans Pop <elendil@...net.nl>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: page allocation failure message kernel 2.6.31.4 (tty-related)
On Thu, Oct 22, 2009 at 03:36:04PM +0300, Pekka Enberg wrote:
> On Thu, Oct 22, 2009 at 1:59 PM, Mel Gorman <mel@....ul.ie> wrote:
> >> There's subtleties like where rt tasks are given ALLOC_HARDER even when
> >> in_interrupt() that are different from previous kernels and could reduce
> >> the amount of ALLOC_HIGH and ALLOC_HARDER memory that can be allocated.
> >>
> >
> > /me checks again
> >
> > I think you're right. Correct it with something like?
> >
> > ==== CUT HERE ====
> > From bca71e94e10cd93771ec5b17eccb817dd0c85360 Mon Sep 17 00:00:00 2001
> > From: Mel Gorman <mel@....ul.ie>
> > Date: Thu, 22 Oct 2009 11:55:14 +0100
> > Subject: [PATCH] page allocator: Do not allow interrupts to use ALLOC_HARDER
> >
> > 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.
> >
> > Signed-off-by: Mel Gorman <mel@....ul.ie>
>
> Good catch.
>
> Reviewed-by: Pekka Enberg <penberg@...helsinki.fi>
>
> Can we have some of the people that are hitting the OOM problems test
> this patch in combination with this patch:
>
> http://patchwork.kernel.org/patch/54215/
>
> Mel, can you also resend these page allocator patches to Andrew? I
> haven't seen him pick the above patch in -mm and we probably want to
> get fixes into -stable soon because distributors seem to be basing
> their next releases on 2.6.31...
>
What I'm going to do is prepare a set that assembles all the possible patches
that fix the variety of errors and get people to retest to make sure we catch
what is relevant, what isn't and what bugs (if any) are left. I should have
the set ready by the end of the day.
> > ---
> > mm/page_alloc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index a3e5fed..3ecf819 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))) {
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists