From: Zhang Yanfei <[email protected]>
Since we have an unlikely for the "current_order >= pageblock_order / 2"
test above, adding an unlikely for this "current_order >= pageblock_order"
test seems more appropriate.
Signed-off-by: Zhang Yanfei <[email protected]>
---
mm/page_alloc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c3edb62..1b6d7de 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1071,7 +1071,7 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
rmv_page_order(page);
/* Take ownership for orders >= pageblock_order */
- if (current_order >= pageblock_order &&
+ if (unlikely(current_order >= pageblock_order) &&
!is_migrate_cma(migratetype))
change_pageblock_range(page, current_order,
start_migratetype);
--
1.7.1
On Sat, 15 Jun 2013, Zhang Yanfei wrote:
> From: Zhang Yanfei <[email protected]>
>
> Since we have an unlikely for the "current_order >= pageblock_order / 2"
> test above, adding an unlikely for this "current_order >= pageblock_order"
> test seems more appropriate.
>
I don't understand the justification at all, current_order being unlikely
greater than or equal to pageblock_order / 2 doesn't imply at all that
it's unlikely that current_order is greater than or equal to
pageblock_order.
> Signed-off-by: Zhang Yanfei <[email protected]>
> ---
> mm/page_alloc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c3edb62..1b6d7de 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1071,7 +1071,7 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype)
> rmv_page_order(page);
>
> /* Take ownership for orders >= pageblock_order */
> - if (current_order >= pageblock_order &&
> + if (unlikely(current_order >= pageblock_order) &&
> !is_migrate_cma(migratetype))
> change_pageblock_range(page, current_order,
> start_migratetype);
Hi David,
On 06/17/2013 02:04 AM, David Rientjes wrote:
> On Sat, 15 Jun 2013, Zhang Yanfei wrote:
>
>> From: Zhang Yanfei <[email protected]>
>>
>> Since we have an unlikely for the "current_order >= pageblock_order / 2"
>> test above, adding an unlikely for this "current_order >= pageblock_order"
>> test seems more appropriate.
>>
>
> I don't understand the justification at all, current_order being unlikely
> greater than or equal to pageblock_order / 2 doesn't imply at all that
> it's unlikely that current_order is greater than or equal to
> pageblock_order.
>
hmmm... I am confused. Since current_order is >= pageblock_order / 2 is unlikely,
why current_order is >= pageblock_order isn't unlikely. Or there are other
tips?
Actually, I am also a little confused about why current_order should be
unlikely greater than or equal to pageblock_order / 2. When borrowing pages
with other migrate_type, we always search from MAX_ORDER-1, which is greater
or equal to pageblock_order.
--
Thanks.
Zhang Yanfei
On Mon, 17 Jun 2013, Zhang Yanfei wrote:
> > I don't understand the justification at all, current_order being unlikely
> > greater than or equal to pageblock_order / 2 doesn't imply at all that
> > it's unlikely that current_order is greater than or equal to
> > pageblock_order.
> >
>
> hmmm... I am confused. Since current_order is >= pageblock_order / 2 is unlikely,
> why current_order is >= pageblock_order isn't unlikely. Or there are other
> tips?
>
> Actually, I am also a little confused about why current_order should be
> unlikely greater than or equal to pageblock_order / 2. When borrowing pages
> with other migrate_type, we always search from MAX_ORDER-1, which is greater
> or equal to pageblock_order.
>
Look at what is being done in the function: current_order loops down from
MAX_ORDER-1 to the order passed. It is not at all "unlikely" that
current_order is greater than pageblock_order, or pageblock_order / 2.
MAX_ORDER is typically 11 and pageblock_order is typically 9 on x86.
Integer division truncates, so pageblock_order / 2 is 4. For the first
eight iterations, it's guaranteed that current_order >= pageblock_order /
2 if it even gets that far!
So just remove the unlikely() entirely, it's completely bogus.
On 06/18/2013 05:37 AM, David Rientjes wrote:
> On Mon, 17 Jun 2013, Zhang Yanfei wrote:
>
>>> I don't understand the justification at all, current_order being unlikely
>>> greater than or equal to pageblock_order / 2 doesn't imply at all that
>>> it's unlikely that current_order is greater than or equal to
>>> pageblock_order.
>>>
>>
>> hmmm... I am confused. Since current_order is >= pageblock_order / 2 is unlikely,
>> why current_order is >= pageblock_order isn't unlikely. Or there are other
>> tips?
>>
>> Actually, I am also a little confused about why current_order should be
>> unlikely greater than or equal to pageblock_order / 2. When borrowing pages
>> with other migrate_type, we always search from MAX_ORDER-1, which is greater
>> or equal to pageblock_order.
>>
>
> Look at what is being done in the function: current_order loops down from
> MAX_ORDER-1 to the order passed. It is not at all "unlikely" that
> current_order is greater than pageblock_order, or pageblock_order / 2.
>
> MAX_ORDER is typically 11 and pageblock_order is typically 9 on x86.
> Integer division truncates, so pageblock_order / 2 is 4. For the first
> eight iterations, it's guaranteed that current_order >= pageblock_order /
> 2 if it even gets that far!
>
> So just remove the unlikely() entirely, it's completely bogus.
I see. Thanks!
I will send another patch.
--
Thanks.
Zhang Yanfei