Mark Lord wrote:Mark Lord wrote:..Mark Lord wrote:..Andrew Morton wrote:..On Thu, 13 Dec 2007 17:15:06 -0500..
James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 2007-12-13 at 14:02 -0800, Andrew Morton wrote:On Thu, 13 Dec 2007 21:09:59 +0100The simple way seems to be to malloc a large area, touch every page and
Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:
OK, it's a vm issue,cc linux-mm and probable culprit.
I have tens of thousand "backward" pages after aBill Irwin fixed this a couple of years back: changed the page allocator so
boot - IOW, bvec->bv_page is the page before bvprv->bv_page, not
reverse. So it looks like that bug got reintroduced.
that it mostly hands out pages in ascending physical-address order.
I guess we broke that, quite possibly in Mel's page allocator rework.
It would help if you could provide us with a simple recipe for
demonstrating this problem, please.
then look at the physical pages assigned ... they now mostly seem to be
descending in physical address.
OIC. -mm's /proc/pid/pagemap can be used to get the pfn's...
I'm actually running the treadmill right now (have been for many hours, actually,
to bisect it to a specific commit.
Thought I was almost done, and then noticed that git-bisect doesn't keep
the Makefile VERSION lines the same, so I was actually running the wrong
kernel after the first few times.. duh.
Wrote a script to fix it now.
Well, that was a waste of three hours.
Ahh.. it seems to be sensitive to one/both of these:
CONFIG_HIGHMEM64G=y with 4GB RAM: not so bad, frequently does 20KB - 48KB segments.
CONFIG_HIGHMEM4G=y with 2GB RAM: very severe, rarely does more than 8KB segments.
CONFIG_HIGHMEM4G=y with 3GB RAM: very severe, rarely does more than 8KB segments.
So if you want to reproduce this on a large memory machine, use "mem=2GB" for starters.
Here's the commit that causes the regression:
535131e6925b4a95f321148ad7293f496e0e58d7 Choose pages from the per-cpu list based on migration type