From: Mark Lord <liml@rtr.ca>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrew Morton <akpm@linux-foundation.org>,
James.Bottomley@HansenPartnership.com, jens.axboe@oracle.com,
lkml@rtr.ca, matthew@wil.cx, linux-ide@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH] fix page_alloc for larger I/O segments (improved)
Date: Fri, 14 Dec 2007 13:07:51 -0500 [thread overview]
Message-ID: <4762C677.5040708@rtr.ca> (raw)
In-Reply-To: <20071214174236.GA28613@csn.ul.ie>
Mel Gorman wrote:
> On (13/12/07 19:46), Mark Lord didst pronounce:
>> "Improved version", more similar to the 2.6.23 code:
>>
>> Fix page allocator to give better chance of larger contiguous segments
>> (again).
>>
>> Signed-off-by: Mark Lord <mlord@pobox.com
>
> Regrettably this interferes with anti-fragmentation because the "next" page
> on the list on return from rmqueue_bulk is not guaranteed to be of the right
> mobility type. I fixed it as an additional patch but it adds additional cost
> that should not be necessary and it's visible in microbenchmark results on
> at least one machine.
>
> The following patch should fix the page ordering problem without incurring an
> additional cost or interfering with anti-fragmentation. However, I haven't
> anything in place yet to verify that the physical page ordering is correct
> but it makes sense. Can you verify it fixes the problem please?
>
> It'll still be some time before I have a full set of performance results
> but initially at least, this fix seems to avoid any impact.
>
> ======
> Subject: Fix page allocation for larger I/O segments
>
> In some cases the IO subsystem is able to merge requests if the pages are
> adjacent in physical memory. This was achieved in the allocator by having
> expand() return pages in physically contiguous order in situations were
> a large buddy was split. However, list-based anti-fragmentation changed
> the order pages were returned in to avoid searching in buffered_rmqueue()
> for a page of the appropriate migrate type.
>
> This patch restores behaviour of rmqueue_bulk() preserving the physical order
> of pages returned by the allocator without incurring increased search costs for
> anti-fragmentation.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> ---
> page_alloc.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.24-rc5-clean/mm/page_alloc.c linux-2.6.24-rc5-giveback-physorder-listmove/mm/page_alloc.c
> --- linux-2.6.24-rc5-clean/mm/page_alloc.c 2007-12-14 11:55:13.000000000 +0000
> +++ linux-2.6.24-rc5-giveback-physorder-listmove/mm/page_alloc.c 2007-12-14 15:33:12.000000000 +0000
> @@ -847,8 +847,19 @@ static int rmqueue_bulk(struct zone *zon
> struct page *page = __rmqueue(zone, order, migratetype);
> if (unlikely(page == NULL))
> break;
> +
> + /*
> + * Split buddy pages returned by expand() are received here
> + * in physical page order. The page is added to the callers and
> + * list and the list head then moves forward. From the callers
> + * perspective, the linked list is ordered by page number in
> + * some conditions. This is useful for IO devices that can
> + * merge IO requests if the physical pages are ordered
> + * properly.
> + */
> list_add(&page->lru, list);
> set_page_private(page, migratetype);
> + list = &page->lru;
> }
> spin_unlock(&zone->lock);
> return i;
..
That (also) works for me here, regularly generating 64KB I/O segments with SLAB.
Cheers
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-12-14 18:07 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071213185326.GQ26334@parisc-linux.org>
[not found] ` <4761821F.3050602@rtr.ca>
[not found] ` <20071213192633.GD10104@kernel.dk>
[not found] ` <4761883A.7050908@rtr.ca>
[not found] ` <476188C4.9030802@rtr.ca>
[not found] ` <20071213193937.GG10104@kernel.dk>
[not found] ` <47618B0B.8020203@rtr.ca>
[not found] ` <20071213195350.GH10104@kernel.dk>
[not found] ` <20071213200219.GI10104@kernel.dk>
[not found] ` <476190BE.9010405@rtr.ca>
[not found] ` <20071213200958.GK10104@kernel.dk>
2007-12-13 22:02 ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Andrew Morton
2007-12-13 22:15 ` James Bottomley
2007-12-13 22:29 ` Andrew Morton
2007-12-13 22:33 ` Mark Lord
2007-12-13 23:13 ` Mark Lord
2007-12-14 0:05 ` Mark Lord
2007-12-14 0:30 ` Mark Lord
2007-12-14 0:37 ` Andrew Morton
2007-12-14 0:42 ` Mark Lord
2007-12-14 0:46 ` [PATCH] fix page_alloc for larger I/O segments (improved) Mark Lord
2007-12-14 0:57 ` James Bottomley
2007-12-14 1:11 ` Andrew Morton
2007-12-14 2:23 ` Mark Lord
2007-12-14 17:42 ` Mel Gorman
2007-12-14 18:07 ` Mark Lord [this message]
2007-12-16 21:56 ` Mel Gorman
2007-12-14 18:13 ` Matthew Wilcox
2007-12-14 18:30 ` Mark Lord
2007-12-20 22:37 ` Matthew Wilcox
2007-12-14 0:47 ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mark Lord
2007-12-14 11:50 ` Mel Gorman
2007-12-14 13:57 ` Mark Lord
2007-12-14 0:40 ` [PATCH] fix page_alloc for larger I/O segments Mark Lord
2007-12-14 1:03 ` Andrew Morton
2007-12-14 4:00 ` Matthew Wilcox
2007-12-15 1:09 ` QUEUE_FLAG_CLUSTER: not working in 2.6.24 ? Mel Gorman
2007-12-15 2:02 ` Andrew Morton
2007-12-15 5:55 ` Matt Mackall
2007-12-16 21:55 ` Mel Gorman
2007-12-17 19:24 ` Randy Dunlap
2007-12-18 2:42 ` Matt Mackall
2007-12-13 22:17 ` Jens Axboe
2007-12-13 22:02 ` VM allocates pages in reverse order again Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4762C677.5040708@rtr.ca \
--to=liml@rtr.ca \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=jens.axboe@oracle.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lkml@rtr.ca \
--cc=matthew@wil.cx \
--cc=mel@csn.ul.ie \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox