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 from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
