Hello all,
is this something to worry about, I saw several of those:
Oct 20 11:25:41 box kernel: ssh: page allocation failure. order:1, mode:0x20
Oct 20 11:25:41 box kernel: Pid: 2970, comm: ssh Tainted: G M 2.6.31.4 #1
Oct 20 11:25:41 box kernel: Call Trace:
Oct 20 11:25:41 box kernel: [<c105545c>] ? __alloc_pages_nodemask+0x404/0x446
Oct 20 11:25:41 box kernel: [<c106e1d1>] ? cache_alloc_refill+0x249/0x42d
Oct 20 11:25:41 box kernel: [<c106e41c>] ? __kmalloc+0x67/0x9e
Oct 20 11:25:41 box kernel: [<c1147c5a>] ? tty_buffer_request_room+0xa9/0x112
Oct 20 11:25:42 box kernel: [<c1147deb>] ? tty_insert_flip_string+0x24/0x90
Oct 20 11:25:42 box kernel: [<c114869e>] ? pty_write+0x25/0x3f
Oct 20 11:25:42 box kernel: [<c1144b6f>] ? n_tty_write+0x23d/0x2d5
Oct 20 11:25:42 box kernel: [<c1021cc7>] ? default_wake_function+0x0/0x8
Oct 20 11:25:42 box kernel: [<c1142ab7>] ? tty_write+0x144/0x1b3
Oct 20 11:25:42 box kernel: [<c1144932>] ? n_tty_write+0x0/0x2d5
Oct 20 11:25:42 box kernel: [<c1142973>] ? tty_write+0x0/0x1b3
Oct 20 11:25:42 box kernel: [<c107238b>] ? vfs_write+0x84/0x105
Oct 20 11:25:42 box kernel: [<c10724a4>] ? sys_write+0x3c/0x63
Oct 20 11:25:42 box kernel: [<c1002804>] ? sysenter_do_call+0x12/0x22
Oct 20 11:25:44 box kernel: DMA per-cpu:
Oct 20 11:25:44 box kernel: CPU 0: hi: 0, btch: 1 usd: 0
Oct 20 11:25:44 box kernel: CPU 1: hi: 0, btch: 1 usd: 0
Oct 20 11:25:44 box kernel: Normal per-cpu:
Oct 20 11:25:44 box kernel: CPU 0: hi: 186, btch: 31 usd: 193
Oct 20 11:25:44 box kernel: CPU 1: hi: 186, btch: 31 usd: 46
Oct 20 11:25:44 box kernel: HighMem per-cpu:
Oct 20 11:25:44 box kernel: CPU 0: hi: 186, btch: 31 usd: 157
Oct 20 11:25:44 box kernel: CPU 1: hi: 186, btch: 31 usd: 142
Oct 20 11:25:44 box kernel: Active_anon:89762 active_file:96664 inactive_anon:23257
Oct 20 11:25:44 box kernel: inactive_file:119147 unevictable:0 dirty:53 writeback:0 unstable:0
Oct 20 11:25:45 box kernel: free:569624 slab:38452 mapped:14421 pagetables:977 bounce:0
Oct 20 11:25:45 box kernel: DMA free:3488kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:8980kB inactive_file:3024kB unevictable:0kB present:15804kB pages_scanned:0 all_unreclaima
Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 865 3698 3698
Oct 20 11:25:45 box kernel: Normal free:5468kB min:3728kB low:4660kB high:5592kB active_anon:0kB inactive_anon:0kB active_file:324840kB inactive_file:330196kB unevictable:0kB present:885944kB pages_scanned:0
Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 0 22669 22669
Oct 20 11:25:45 box kernel: HighMem free:2269540kB min:512kB low:3564kB high:6616kB active_anon:359048kB inactive_anon:93028kB active_file:52836kB inactive_file:143368kB unevictable:0kB present:2901640kB page
Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 0 0 0
Oct 20 11:25:45 box kernel: DMA: 172*4kB 6*8kB 0*16kB 0*32kB 3*64kB 2*128kB 3*256kB 3*512kB 0*1024kB 0*2048kB 0*4096kB = 3488kB
Oct 20 11:25:45 box kernel: Normal: 1232*4kB 83*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5592kB
Oct 20 11:25:45 box kernel: HighMem: 45*4kB 80*8kB 69*16kB 29*32kB 29*64kB 22*128kB 14*256kB 9*512kB 3*1024kB 3*2048kB 548*4096kB = 2269540kB
Oct 20 11:25:45 box kernel: 216788 total pagecache pages
Oct 20 11:25:45 box kernel: 0 pages in swap cache
Oct 20 11:25:45 box kernel: Swap cache stats: add 0, delete 0, find 0/0
Oct 20 11:25:45 box kernel: Free swap = 2104472kB
Oct 20 11:25:45 box kernel: Total swap = 2104472kB
--
Regards,
Stephan
[ tty related CCs added ]
On Tue, 20 Oct 2009, Stephan von Krawczynski wrote:
> Hello all,
>
> is this something to worry about, I saw several of those:
>
> Oct 20 11:25:41 box kernel: ssh: page allocation failure. order:1, mode:0x20
> Oct 20 11:25:41 box kernel: Pid: 2970, comm: ssh Tainted: G M 2.6.31.4 #1
> Oct 20 11:25:41 box kernel: Call Trace:
> Oct 20 11:25:41 box kernel: [<c105545c>] ? __alloc_pages_nodemask+0x404/0x446
> Oct 20 11:25:41 box kernel: [<c106e1d1>] ? cache_alloc_refill+0x249/0x42d
> Oct 20 11:25:41 box kernel: [<c106e41c>] ? __kmalloc+0x67/0x9e
> Oct 20 11:25:41 box kernel: [<c1147c5a>] ? tty_buffer_request_room+0xa9/0x112
> Oct 20 11:25:42 box kernel: [<c1147deb>] ? tty_insert_flip_string+0x24/0x90
> Oct 20 11:25:42 box kernel: [<c114869e>] ? pty_write+0x25/0x3f
> Oct 20 11:25:42 box kernel: [<c1144b6f>] ? n_tty_write+0x23d/0x2d5
> Oct 20 11:25:42 box kernel: [<c1021cc7>] ? default_wake_function+0x0/0x8
> Oct 20 11:25:42 box kernel: [<c1142ab7>] ? tty_write+0x144/0x1b3
> Oct 20 11:25:42 box kernel: [<c1144932>] ? n_tty_write+0x0/0x2d5
> Oct 20 11:25:42 box kernel: [<c1142973>] ? tty_write+0x0/0x1b3
> Oct 20 11:25:42 box kernel: [<c107238b>] ? vfs_write+0x84/0x105
> Oct 20 11:25:42 box kernel: [<c10724a4>] ? sys_write+0x3c/0x63
> Oct 20 11:25:42 box kernel: [<c1002804>] ? sysenter_do_call+0x12/0x22
> Oct 20 11:25:44 box kernel: DMA per-cpu:
> Oct 20 11:25:44 box kernel: CPU 0: hi: 0, btch: 1 usd: 0
> Oct 20 11:25:44 box kernel: CPU 1: hi: 0, btch: 1 usd: 0
> Oct 20 11:25:44 box kernel: Normal per-cpu:
> Oct 20 11:25:44 box kernel: CPU 0: hi: 186, btch: 31 usd: 193
> Oct 20 11:25:44 box kernel: CPU 1: hi: 186, btch: 31 usd: 46
> Oct 20 11:25:44 box kernel: HighMem per-cpu:
> Oct 20 11:25:44 box kernel: CPU 0: hi: 186, btch: 31 usd: 157
> Oct 20 11:25:44 box kernel: CPU 1: hi: 186, btch: 31 usd: 142
> Oct 20 11:25:44 box kernel: Active_anon:89762 active_file:96664 inactive_anon:23257
> Oct 20 11:25:44 box kernel: inactive_file:119147 unevictable:0 dirty:53 writeback:0 unstable:0
> Oct 20 11:25:45 box kernel: free:569624 slab:38452 mapped:14421 pagetables:977 bounce:0
> Oct 20 11:25:45 box kernel: DMA free:3488kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:8980kB inactive_file:3024kB unevictable:0kB present:15804kB pages_scanned:0 all_unreclaima
> Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 865 3698 3698
> Oct 20 11:25:45 box kernel: Normal free:5468kB min:3728kB low:4660kB high:5592kB active_anon:0kB inactive_anon:0kB active_file:324840kB inactive_file:330196kB unevictable:0kB present:885944kB pages_scanned:0
> Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 0 22669 22669
> Oct 20 11:25:45 box kernel: HighMem free:2269540kB min:512kB low:3564kB high:6616kB active_anon:359048kB inactive_anon:93028kB active_file:52836kB inactive_file:143368kB unevictable:0kB present:2901640kB page
> Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 0 0 0
> Oct 20 11:25:45 box kernel: DMA: 172*4kB 6*8kB 0*16kB 0*32kB 3*64kB 2*128kB 3*256kB 3*512kB 0*1024kB 0*2048kB 0*4096kB = 3488kB
> Oct 20 11:25:45 box kernel: Normal: 1232*4kB 83*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5592kB
> Oct 20 11:25:45 box kernel: HighMem: 45*4kB 80*8kB 69*16kB 29*32kB 29*64kB 22*128kB 14*256kB 9*512kB 3*1024kB 3*2048kB 548*4096kB = 2269540kB
> Oct 20 11:25:45 box kernel: 216788 total pagecache pages
> Oct 20 11:25:45 box kernel: 0 pages in swap cache
> Oct 20 11:25:45 box kernel: Swap cache stats: add 0, delete 0, find 0/0
> Oct 20 11:25:45 box kernel: Free swap = 2104472kB
> Oct 20 11:25:45 box kernel: Total swap = 2104472kB
>
>
>
--
Jiri Kosina
SUSE Labs, Novell Inc.
On Wed, 21 Oct 2009, Jiri Kosina wrote:
> [ tty related CCs added ]
>
I think this is probably a duplicate of the GFP_ATOMIC page allocator
issue at http://bugzilla.kernel.org/show_bug.cgi?id=14141 more than a tty
issue.
Have we tried rolling back the refactored page allocator changes in 2.6.31
to see if the logic has changed in other ways unrelated to kswapd?
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.
> On Tue, 20 Oct 2009, Stephan von Krawczynski wrote:
>
> > Hello all,
> >
> > is this something to worry about, I saw several of those:
> >
> > Oct 20 11:25:41 box kernel: ssh: page allocation failure. order:1, mode:0x20
> > Oct 20 11:25:41 box kernel: Pid: 2970, comm: ssh Tainted: G M 2.6.31.4 #1
> > Oct 20 11:25:41 box kernel: Call Trace:
> > Oct 20 11:25:41 box kernel: [<c105545c>] ? __alloc_pages_nodemask+0x404/0x446
> > Oct 20 11:25:41 box kernel: [<c106e1d1>] ? cache_alloc_refill+0x249/0x42d
> > Oct 20 11:25:41 box kernel: [<c106e41c>] ? __kmalloc+0x67/0x9e
> > Oct 20 11:25:41 box kernel: [<c1147c5a>] ? tty_buffer_request_room+0xa9/0x112
> > Oct 20 11:25:42 box kernel: [<c1147deb>] ? tty_insert_flip_string+0x24/0x90
> > Oct 20 11:25:42 box kernel: [<c114869e>] ? pty_write+0x25/0x3f
> > Oct 20 11:25:42 box kernel: [<c1144b6f>] ? n_tty_write+0x23d/0x2d5
> > Oct 20 11:25:42 box kernel: [<c1021cc7>] ? default_wake_function+0x0/0x8
> > Oct 20 11:25:42 box kernel: [<c1142ab7>] ? tty_write+0x144/0x1b3
> > Oct 20 11:25:42 box kernel: [<c1144932>] ? n_tty_write+0x0/0x2d5
> > Oct 20 11:25:42 box kernel: [<c1142973>] ? tty_write+0x0/0x1b3
> > Oct 20 11:25:42 box kernel: [<c107238b>] ? vfs_write+0x84/0x105
> > Oct 20 11:25:42 box kernel: [<c10724a4>] ? sys_write+0x3c/0x63
> > Oct 20 11:25:42 box kernel: [<c1002804>] ? sysenter_do_call+0x12/0x22
> > Oct 20 11:25:44 box kernel: DMA per-cpu:
> > Oct 20 11:25:44 box kernel: CPU 0: hi: 0, btch: 1 usd: 0
> > Oct 20 11:25:44 box kernel: CPU 1: hi: 0, btch: 1 usd: 0
> > Oct 20 11:25:44 box kernel: Normal per-cpu:
> > Oct 20 11:25:44 box kernel: CPU 0: hi: 186, btch: 31 usd: 193
> > Oct 20 11:25:44 box kernel: CPU 1: hi: 186, btch: 31 usd: 46
> > Oct 20 11:25:44 box kernel: HighMem per-cpu:
> > Oct 20 11:25:44 box kernel: CPU 0: hi: 186, btch: 31 usd: 157
> > Oct 20 11:25:44 box kernel: CPU 1: hi: 186, btch: 31 usd: 142
> > Oct 20 11:25:44 box kernel: Active_anon:89762 active_file:96664 inactive_anon:23257
> > Oct 20 11:25:44 box kernel: inactive_file:119147 unevictable:0 dirty:53 writeback:0 unstable:0
> > Oct 20 11:25:45 box kernel: free:569624 slab:38452 mapped:14421 pagetables:977 bounce:0
> > Oct 20 11:25:45 box kernel: DMA free:3488kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:8980kB inactive_file:3024kB unevictable:0kB present:15804kB pages_scanned:0 all_unreclaima
> > Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 865 3698 3698
> > Oct 20 11:25:45 box kernel: Normal free:5468kB min:3728kB low:4660kB high:5592kB active_anon:0kB inactive_anon:0kB active_file:324840kB inactive_file:330196kB unevictable:0kB present:885944kB pages_scanned:0
> > Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 0 22669 22669
> > Oct 20 11:25:45 box kernel: HighMem free:2269540kB min:512kB low:3564kB high:6616kB active_anon:359048kB inactive_anon:93028kB active_file:52836kB inactive_file:143368kB unevictable:0kB present:2901640kB page
> > Oct 20 11:25:45 box kernel: lowmem_reserve[]: 0 0 0 0
> > Oct 20 11:25:45 box kernel: DMA: 172*4kB 6*8kB 0*16kB 0*32kB 3*64kB 2*128kB 3*256kB 3*512kB 0*1024kB 0*2048kB 0*4096kB = 3488kB
> > Oct 20 11:25:45 box kernel: Normal: 1232*4kB 83*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 5592kB
> > Oct 20 11:25:45 box kernel: HighMem: 45*4kB 80*8kB 69*16kB 29*32kB 29*64kB 22*128kB 14*256kB 9*512kB 3*1024kB 3*2048kB 548*4096kB = 2269540kB
> > Oct 20 11:25:45 box kernel: 216788 total pagecache pages
> > Oct 20 11:25:45 box kernel: 0 pages in swap cache
> > Oct 20 11:25:45 box kernel: Swap cache stats: add 0, delete 0, find 0/0
> > Oct 20 11:25:45 box kernel: Free swap = 2104472kB
> > Oct 20 11:25:45 box kernel: Total swap = 2104472kB
On Wed, Oct 21, 2009 at 02:16:56PM -0700, David Rientjes wrote:
> On Wed, 21 Oct 2009, Jiri Kosina wrote:
>
> > [ tty related CCs added ]
> >
>
> I think this is probably a duplicate of the GFP_ATOMIC page allocator
> issue at http://bugzilla.kernel.org/show_bug.cgi?id=14141 more than a tty
> issue.
>
Probably.
> Have we tried rolling back the refactored page allocator changes in 2.6.31
> to see if the logic has changed in other ways unrelated to kswapd?
No, but bisects around that area were inconclusive at best and there
are dependants that made backing it out problematic.
> 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 <[email protected]>
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 <[email protected]>
---
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))) {
On Thu, Oct 22, 2009 at 1:59 PM, Mel Gorman <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
Good catch.
Reviewed-by: Pekka Enberg <[email protected]>
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...
> ---
> ?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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Thu, Oct 22, 2009 at 03:36:04PM +0300, Pekka Enberg wrote:
> On Thu, Oct 22, 2009 at 1:59 PM, Mel Gorman <[email protected]> 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 <[email protected]>
> > 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 <[email protected]>
>
> Good catch.
>
> Reviewed-by: Pekka Enberg <[email protected]>
>
> 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 [email protected]
> > 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
On Thu, 22 Oct 2009 13:51:20 +0100
Mel Gorman <[email protected]> wrote:
>
> 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.
Feel free to send, I got lots of those messages, so a change should be very
visible for me.
--
Regards,
Stephan
On Thu, Oct 22, 2009 at 06:06:46PM +0200, Stephan von Krawczynski wrote:
> On Thu, 22 Oct 2009 13:51:20 +0100
> Mel Gorman <[email protected]> wrote:
> >
> > 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.
>
> Feel free to send, I got lots of those messages, so a change should be very
> visible for me.
>
You should have received the patches and test requests in a mail thread
starting with "Candidate fix for increased number of GFP_ATOMIC failures
V2".
Thanks
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
On Thu, 22 Oct 2009, Mel Gorman wrote:
> From bca71e94e10cd93771ec5b17eccb817dd0c85360 Mon Sep 17 00:00:00 2001
> From: Mel Gorman <[email protected]>
> 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 <[email protected]>
Acked-by: David Rientjes <[email protected]>
On 10/22/2009 06:59 AM, Mel Gorman 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.
>
> Signed-off-by: Mel Gorman<[email protected]>
Reviewed-by: Rik van Riel <[email protected]>
--
All rights reversed.