Re: [Bug #14141] order 2 page allocation failures in iwlagn

Frans Pop
2009-10-26T21:06:09Z

[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]

On Tuesday 20 October 2009, Mel Gorman wrote:
> I've attached a patch below that should allow us to cheat. When it's
> applied, it outputs who called congestion_wait(), how long the timeout
> was and how long it waited for. By comparing before and after sleep
> times, we should be able to see which of the callers has significantly
> changed and if it's something easily addressable.

The results from this look fairly interesting (although I may be a bad
judge as I don't really know what I'm looking at ;-).

I've tested with two kernels:
1) 2.6.31.1: 1 test run
2) 2.6.31.1 + congestion_wait() reverts: 2 test runs

The 1st kernel had the expected "freeze" while reading commits in gitk;
reading commits with the 2nd kernel was more fluent.
I did 2 runs with the 2nd kernel as the first run had a fairly long music
skip and more SKB errors than expected. The second run was fairly normal
with no music skips at all even though it had a few SKB errors.

Data for the tests:
1st kernel 2nd kernel 1 2nd kernel 2
end reading commits 1:15 1:00 0:55
"freeze" yes no no
branch data shown 1:55 1:15 1:10
system quiet 2:25 1:50 1:45
# SKB allocation errors 10 53 5

Note that the test is substantially faster with the 2nd kernel and that the
SKB errors don't really affect the duration of the test.

Attached a tarball with the kernel logs, both the full logs and a stripped
version with only the lines generated during the actual test.
Something like this will extract the debug data from the logs:
$ grep "delay " <file> | sed "s/^.*\] //"

Also attached a ODF spreadsheet with a summary of the data for all 3 tests.
I've dropped the congestion_wait and sync/rw= columns as they were always
the same (rw=1 for 1st kernel and sync=0 for 2nd kernel).
I've added a column "weighed delay" and totals for that column and the
count column.

My layman's observations are:
- without the revert 'background_writeout' is called a lot less frequently,
but when it's called it gets long delays
- without the revert you have 'wb_kupdate', which is relatively expensive
- with the revert 'shrink_list' is relatively expensive, although not
really in absolute terms

You people may want to look at exactly what happens directly around the SKB
allocation errors. I've only looked at totals.

Cheers,
FJP

[-- Attachment #2: logs.tgz --]
[-- Type: application/x-tgz, Size: 151463 bytes --]

[-- Attachment #3: results.ods --]
[-- Type: application/vnd.oasis.opendocument.spreadsheet, Size: 20051 bytes --]