* [PATCH] mm : kill combined_idx
@ 2009-12-21 3:32 Huang Shijie
2009-12-21 5:31 ` KAMEZAWA Hiroyuki
0 siblings, 1 reply; 4+ messages in thread
From: Huang Shijie @ 2009-12-21 3:32 UTC (permalink / raw)
To: akpm; +Cc: mel, linux-mm, Huang Shijie
In more then half of all the cases, `page' is head of the buddy pair
{page, buddy} in __free_one_page. That is because the allocation logic
always picks the head of a chunk, and puts the rest back to the buddy system.
So calculating the combined page is not needed but waste some cycles in
more then half of all the cases.Just do the calculation when `page' is
bigger then the `buddy'.
Signed-off-by: Huang Shijie <shijie8@gmail.com>
---
mm/page_alloc.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 4e86965..42351bf 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -464,7 +464,6 @@ static inline void __free_one_page(struct page *page,
VM_BUG_ON(bad_range(zone, page));
while (order < MAX_ORDER-1) {
- unsigned long combined_idx;
struct page *buddy;
buddy = __page_find_buddy(page, page_idx, order);
@@ -475,9 +474,10 @@ static inline void __free_one_page(struct page *page,
list_del(&buddy->lru);
zone->free_area[order].nr_free--;
rmv_page_order(buddy);
- combined_idx = __find_combined_index(page_idx, order);
- page = page + (combined_idx - page_idx);
- page_idx = combined_idx;
+ if (page > buddy) { /* keep `page' the head of the buddy pair */
+ page = buddy;
+ page_idx = __find_combined_index(page_idx, order);
+ }
order++;
}
set_page_order(page, order);
--
1.6.0.6
--
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>
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] mm : kill combined_idx
2009-12-21 3:32 [PATCH] mm : kill combined_idx Huang Shijie
@ 2009-12-21 5:31 ` KAMEZAWA Hiroyuki
2009-12-21 19:43 ` Mel Gorman
0 siblings, 1 reply; 4+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-12-21 5:31 UTC (permalink / raw)
To: Huang Shijie; +Cc: akpm, mel, linux-mm
On Mon, 21 Dec 2009 11:32:27 +0800
Huang Shijie <shijie8@gmail.com> wrote:
> In more then half of all the cases, `page' is head of the buddy pair
> {page, buddy} in __free_one_page. That is because the allocation logic
> always picks the head of a chunk, and puts the rest back to the buddy system.
>
> So calculating the combined page is not needed but waste some cycles in
> more then half of all the cases.Just do the calculation when `page' is
> bigger then the `buddy'.
>
> Signed-off-by: Huang Shijie <shijie8@gmail.com>
Hmm...As far as I remember, this code design was for avoiding "if".
Is this compare+jump is better than add+xor ?
Thanks,
-Kame
--
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm : kill combined_idx
2009-12-21 5:31 ` KAMEZAWA Hiroyuki
@ 2009-12-21 19:43 ` Mel Gorman
2009-12-22 3:11 ` Huang Shijie
0 siblings, 1 reply; 4+ messages in thread
From: Mel Gorman @ 2009-12-21 19:43 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Huang Shijie, akpm, linux-mm
On Mon, Dec 21, 2009 at 02:31:39PM +0900, KAMEZAWA Hiroyuki wrote:
> On Mon, 21 Dec 2009 11:32:27 +0800
> Huang Shijie <shijie8@gmail.com> wrote:
>
> > In more then half of all the cases, `page' is head of the buddy pair
> > {page, buddy} in __free_one_page. That is because the allocation logic
> > always picks the head of a chunk, and puts the rest back to the buddy system.
> >
> > So calculating the combined page is not needed but waste some cycles in
> > more then half of all the cases.Just do the calculation when `page' is
> > bigger then the `buddy'.
> >
> > Signed-off-by: Huang Shijie <shijie8@gmail.com>
>
> Hmm...As far as I remember, this code design was for avoiding "if".
> Is this compare+jump is better than add+xor ?
>
Agreed. It's not clear that a compare+jump is cheaper than the add+xor.
How often it's the case that the page is the higher or lower half of the
buddy would depend heavily on the allocation/free pattern making it
hard, if not possible, to predict which is the more common case.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
--
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] mm : kill combined_idx
2009-12-21 19:43 ` Mel Gorman
@ 2009-12-22 3:11 ` Huang Shijie
0 siblings, 0 replies; 4+ messages in thread
From: Huang Shijie @ 2009-12-22 3:11 UTC (permalink / raw)
To: Mel Gorman; +Cc: KAMEZAWA Hiroyuki, akpm, linux-mm
>> Hmm...As far as I remember, this code design was for avoiding "if".
>> Is this compare+jump is better than add+xor ?
>>
>>
>
> Agreed. It's not clear that a compare+jump is cheaper than the add+xor.
> How often it's the case that the page is the higher or lower half of the
> buddy would depend heavily on the allocation/free pattern making it
> hard, if not possible, to predict which is the more common case.
>
>
ok. thanks a lot.
--
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>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-12-22 3:12 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-21 3:32 [PATCH] mm : kill combined_idx Huang Shijie
2009-12-21 5:31 ` KAMEZAWA Hiroyuki
2009-12-21 19:43 ` Mel Gorman
2009-12-22 3:11 ` Huang Shijie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).