Message ID | 1256221356-26049-3-git-send-email-mel@csn.ul.ie |
---|---|
State | Not Applicable, archived |
Delegated to: | David Miller |
Headers | show |
On Thu, 22 Oct 2009 15:22:33 +0100 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> > --- > 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))) { > -- > 1.6.3.3 > Is it correct that this one applies offset -54 lines in 2.6.31.4 ?
On Thu, Oct 22, 2009 at 06:33:03PM +0200, Stephan von Krawczynski wrote: > On Thu, 22 Oct 2009 15:22:33 +0100 > 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> > > --- > > 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))) { > > -- > > 1.6.3.3 > > > > Is it correct that this one applies offset -54 lines in 2.6.31.4 ? > In this case, it's ok. It's just a harmless heads-up that the kernel looks slightly different than expected. I posted a 2.6.31.4 version of the two patches that cause real problems.
On Thu, 22 Oct 2009 17:37:52 +0100 Mel Gorman <mel@csn.ul.ie> wrote: > In this case, it's ok. It's just a harmless heads-up that the kernel > looks slightly different than expected. I posted a 2.6.31.4 version of > the two patches that cause real problems. After around 12 hours of runtime with patch 1/5 and 2/5 on 2.6.31.4 I can see no page allocation failure messages so far. I'll keep you informed.
There are now rt dependencies in the page allocator that screw things up? And an rt flag causes the page allocator to try harder meaning it adds latency. ? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 22 Oct 2009 17:37:52 +0100 Mel Gorman <mel@csn.ul.ie> wrote: > In this case, it's ok. It's just a harmless heads-up that the kernel > looks slightly different than expected. I posted a 2.6.31.4 version of > the two patches that cause real problems. After around 12 hours of runtime with patch 1/5 and 2/5 on 2.6.31.4 I can see no page allocation failure messages so far. I'll keep you informed. [Update] After 2 days I still see no failure messages. [/update]
> 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> > --- > 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))) { > -- > 1.6.3.3 good catch. Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 23, 2009 at 10:03:05PM -0400, Christoph Lameter wrote: > There are now rt dependencies in the page allocator that screw things up? > The rt logic was present before. > And an rt flag causes the page allocator to try harder meaning it adds > latency. > The harder term in the flag is a bit misleading. The effect of ALLOC_HARDER is that the watermark is lower for the task. i.e. a rt task is less likely to enter direct reclaim than normal tasks so it should have less latency. > ? > >
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))) {