Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2

[PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-10-22
[PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · Mel Gorman <hidden> · 2009-10-22
[PATCH 1/5 Against 2.6.31.4] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · Pekka Enberg <hidden> · 2009-10-22
Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · KOSAKI Motohiro <hidden> · 2009-10-26
Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · David Rientjes <rientjes@google.com> · 2009-10-26
Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · KOSAKI Motohiro <hidden> · 2009-10-27
Re: [PATCH 1/5] page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed · Mel Gorman <hidden> · 2009-10-27
[PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · Stephan von Krawczynski <hidden> · 2009-10-22
Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · Stephan von Krawczynski <hidden> · 2009-10-23
Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · Christoph Lameter <hidden> · 2009-10-24
Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · Mel Gorman <hidden> · 2009-10-27
Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · Stephan von Krawczynski <hidden> · 2009-10-25
Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER · KOSAKI Motohiro <hidden> · 2009-10-26
[PATCH 5/5] ONLY-APPLY-IF-STILL-FAILING Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs read/write confusion · Mel Gorman <hidden> · 2009-10-22
Against 2.6.31.4 [PATCH 5/5] Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs read/write confusion · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 5/5] ONLY-APPLY-IF-STILL-FAILING Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs read/write confusion · Jens Axboe <hidden> · 2009-10-22
Re: [PATCH 5/5] ONLY-APPLY-IF-STILL-FAILING Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs read/write confusion · KOSAKI Motohiro <hidden> · 2009-10-27
Re: [PATCH 5/5] ONLY-APPLY-IF-STILL-FAILING Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs read/write confusion · Frans Pop <hidden> · 2009-10-27
[PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · David Rientjes <rientjes@google.com> · 2009-10-22
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · Mel Gorman <hidden> · 2009-10-23
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · David Rientjes <rientjes@google.com> · 2009-10-23
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · Mel Gorman <hidden> · 2009-10-23
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · Tobias Oetiker <hidden> · 2009-10-23
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · Mel Gorman <hidden> · 2009-10-23
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · KOSAKI Motohiro <hidden> · 2009-10-27
Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit · Mel Gorman <hidden> · 2009-10-27
[PATCH 3/5] vmscan: Force kswapd to take notice faster when high-order watermarks are being hit · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 3/5] vmscan: Force kswapd to take notice faster when high-order watermarks are being hit · KOSAKI Motohiro <hidden> · 2009-10-27
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Pekka Enberg <hidden> · 2009-10-22
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-10-22
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Christoph Lameter <hidden> · 2009-10-24
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Pekka Enberg <hidden> · 2009-10-24
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · reinette chatre <reinette.chatre@intel.com> · 2009-10-22
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-10-27
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · reinette chatre <reinette.chatre@intel.com> · 2009-10-27
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Sven Geggus <hidden> · 2009-10-23
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Karol Lewandowski <hidden> · 2009-10-23
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Karol Lewandowski <hidden> · 2009-10-23
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel LKML <hidden> · 2009-10-24
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Karol Lewandowski <hidden> · 2009-10-28
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-10-28
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Karol Lewandowski <hidden> · 2009-10-30
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-11-02
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Karol Lewandowski <hidden> · 2009-11-04
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Tobi Oetiker <hidden> · 2009-10-28
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Frans Pop <hidden> · 2009-10-24
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Sven Geggus <hidden> · 2009-10-24
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-10-27
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Tobias Oetiker <hidden> · 2009-10-26
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-10-27
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Frans Pop <hidden> · 2009-10-26
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Frans Pop <hidden> · 2009-10-27
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Tobias Diedrich <hidden> · 2009-11-06
Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2 · Mel Gorman <hidden> · 2009-11-06

From: Mel Gorman <hidden>
Date: 2009-10-27 13:27:05
Also in: linux-mm, lkml

On Sat, Oct 24, 2009 at 04:02:09PM +0200, Sven Geggus wrote:

Mel Gorman schrieb am Donnerstag, den 22. Oktober um 16:22 Uhr:

quoted

Test 1: Verify your problem occurs on 2.6.32-rc5 if you can

Problem persists. RAID resync in progress :(

What about the rest of the patches, any luck?

Thanks

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help