On Thu, Dec 13 2007, Andrew Morton wrote: > On Thu, 13 Dec 2007 21:09:59 +0100 > 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 a > > boot - IOW, bvec->bv_page is the page before bvprv->bv_page, not > > reverse. So it looks like that bug got reintroduced. > > Bill Irwin fixed this a couple of years back: changed the page allocator so > 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. Basically anything involving IO :-). A boot here showed a handful of good merges, and probably in the order of 100,000 descending allocations. A kernel make is a fine test as well. Something like the below should work fine - if you see oodles of these basicaly doing any type of IO, then you are screwed. diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c index e30b1a4..8ce3fcc 100644 --- a/block/ll_rw_blk.c +++ b/block/ll_rw_blk.c @@ -1349,6 +1349,10 @@ new_segment: sg = sg_next(sg); } + if (bvprv) { + if (page_address(bvec->bv_page) + PAGE_SIZE == page_address(bvprv->bv_page) && printk_ratelimit()) + printk("page alloc order backwards\n"); + } sg_set_page(sg, bvec->bv_page, nbytes, bvec->bv_offset); nsegs++; } -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html