lkml.org 
[lkml]   [2009]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
Date
On Thursday 22 October 2009, Mel Gorman wrote:
> Test 1: Verify your problem occurs on 2.6.32-rc5 if you can

I've tested against 2.6.31.1 as it's easier for me to compare behaviors
with that than with .32. All patches applied without problems against .31.

I've also tested 2.6.31.1 with SLAB instead of SLUB, but that does not seem
to make a significant difference for my test.

> Test 2: Apply the following two patches and test again
> 1/5 page allocator: Always wake kswapd when restarting an allocation
> attempt after direct reclaim failed
> 2/5 page allocator: Do not allow interrupts to use ALLOC_HARDER

Does not look to make any difference. Possibly causes more variation in the
duration of the test (increases timing effects)?

> Test 3: If you are getting allocation failures, try with the following
> patch
> 3/5 vmscan: Force kswapd to take notice faster when high-order
> watermarks are being hit

Applied on top of patches 1-2. Does not look to make any difference.

> Test 4: If you are still getting failures, apply the following
> 4/5 page allocator: Pre-emptively wake kswapd when high-order
> watermarks are hit

Applied on top of patches 1-3. Does not look to make any difference.

> Test 5: If things are still screwed, apply the following
> 5/5 Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs
> read/write confusion

Applied on top of patches 1-4. Despite Jens' scepticism is this still the
patch that makes the most significant difference in my test.
The reading of commits in gitk is much more fluent and music skips are a
lot less severe. But most important is that there is no long total freeze
of the system halfway during the reading of commits and gitk loads
fastest. It also gives by far the most consistent results.
The likelyhood of SKB allocation errors during the test is a lot smaller.
See also http://lkml.org/lkml/2009/10/26/455.


Detailed test results follow. I've done 2 test runs with each kernel (3 for
the last).

The columns below give the following info:
- time at which all commits have been read by gitk
- time at which gitk fills in "branch", "follows" and "precedes" data for
the current commit
- time at which there's no longer any disk activity, i.e. when gitk is
fully loaded and all swapping is done
- total number of SKB allocation errors during the test
A "freeze" during the reading of commits is indicated by an "f" (short
freeze) or "F" (long "hard" freeze). An "S" shows when there were SKB
allocation errors.

end commits show branch done SKB errs
1) vanilla .31.1
run 1: 1:20 fFS 2:10 S 2:30 44 a)
run 2: 1:35 FS 1:45 2:10 13

2) .31.1 + patches 1-2
run1: 2:30 fFS 2:45 3:00 58
run2: 1:15 fS 2:00 2:20 2 a)

3) .31.1 + patches 1-3
run1: 1:00 fS 1:15 1:45 1 *)
run2: 3:00 fFS 3:15 3:30 33
*) unexpected; fortunate timing?

4) .31.1 + patches 1-4
run1: 1:10 ffS 1:55 S 2:20 35 a)
run2: 3:05 fFS 3:15 3:25 36

5) .31.1 + patches 1-5
run1: 1:00 1:15 1:35 0
run2: 0:50 1:15 S 1:45 45 *)
run3: 1:00 1:15 1:45 0
*) unexpected; unfortunate timing?

a) fast in 1st phase; slow in 2nd and 3rd

Note that without the congestion_wait() reverts occurrence of SKB errors,
the long freezes and time it takes for gitk to load seem roughly related;
with the reverts total time is not affected even with many SKB errors.

Cheers,
FJP


\
 
 \ /
  Last update: 2009-10-26 23:21    [W:0.437 / U:0.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site