On 08/11/2014 02:12 PM, Mel Gorman wrote:
On Fri, Aug 08, 2014 at 05:27:15PM +0200, Vlastimil Babka wrote:
On 07/09/2014 10:13 AM, Mel Gorman wrote:
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1604,6 +1604,9 @@ again:
}
__mod_zone_page_state(zone, NR_ALLOC_BATCH, -(1 << order));
This can underflow zero, right?
Yes, because of per-cpu accounting drift.
I meant mainly because of order > 0.
+ if (zone_page_state(zone, NR_ALLOC_BATCH) == 0 &&
AFAICS, zone_page_state will correct negative values to zero only for
CONFIG_SMP. Won't this check be broken on !CONFIG_SMP?
On !CONFIG_SMP how can there be per-cpu accounting drift that would make
that counter negative?
Well original code used "if (zone_page_state(zone, NR_ALLOC_BATCH) <=
0)" elsewhere, that you are replacing with zone_is_fair_depleted check.
I assumed it's because it can get negative due to order > 0. I might
have not looked thoroughly enough but it seems to me there's nothing
that would prevent it, such as skipping a zone because its remaining
batch is lower than 1 << order.
So I think the check should be "<= 0" to be safe.
Vlastimil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>