Re: Performance regression in scsi sequential throughput (iozone)due to "e084b - page-allocator: preserve PFN ordering when __GFP_COLD isset"
From: Christian Ehrhardt
Date: Mon Feb 22 2010 - 10:43:14 EST
Mel Gorman wrote:
[...]
Unfortunately even now knowing the place of the issue so well I don't see
the connection to the commits e084b+5f8dcc21
Still a mystery.
- I couldn't find something but
did they change the accounting somewhere or e.g. changed the timing/order
of watermark updates and allocations?
Not that I can think of.
Eventually it might come down to a discussion of allocation priorities and
we might even keep them as is and accept this issue - I still would prefer
a good second chance implementation, other page cache allocation flags or
something else that explicitly solves this issue.
In that line, the patch that replaced congestion_wait() with a waitqueue
makes some sense.
[...]
I'll need to do a number of tests before I can move that upstream but I
don't think it's a merge candidate. Unfortunately, I'll be offline for a
week starting tomorrow so I won't be able to do the testing.
When I get back, I'll revisit those patches with the view to pushing
them upstream. I hate to treat symptoms here without knowing the
underlying problem but this has been spinning in circles for ages with
little forward progress :(
I'll continue with some debugging in search for the real reasons, but if
I can't find a new way to look at it I think we have to drop it for now.
While I hate fixing symptoms too, I completely agree that it is time to
bring this fix upstream and in fact into the stable kernel too, to have
at least a ~98% workaround out there.
I'm looking forward for your revised patch after you are back and I'm
eager to test this one again.
--
Grüsse / regards, Christian Ehrhardt
IBM Linux Technology Center, System z Linux Performance
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/