Re: [PATCH 6/8] Fragmentation Avoidance V17: 006_largealloc_tryharder

From: Joel Schopp
Date: Thu Oct 13 2005 - 14:07:42 EST

This is version 17, plus several versions I did while Mel was preoccupied with his day job, makes well over 20 times this has been posted to the mailing lists that are lkml, linux-mm, and memory hotplug.

All objections/feedback/suggestions that have been brought up on the lists are fixed in the following version. It's starting to become almost silent when a new version gets posted, possibly because everybody accepts the code as perfect, possibly because they have grown bored with it. Probably a combination of both.

I'm guessing the reason this code hasn't been merged yet is because nobody has really enumerated the benefits in awhile. Here's my try at it

Benefits of merging:
1. Reduced Fragmentation
2. Better able to fulfill large allocations (see 1)
3. Less out of memory conditions (see 1)
3. Prereq for memory hotplug remove
4. Would be helpful for future development of active defragmentation
5. Also helpful for future development of demand fault allocating large pages

Downsides of merging:
It's been well tested on multiple architectures in multiple configurations, but non-trivial changes to core subsystems should not be done lightly.

@@ -1203,8 +1204,19 @@ rebalance:
goto got_pg;
- out_of_memory(gfp_mask, order);
+ if (order < MAX_ORDER / 2)
+ out_of_memory(gfp_mask, order);
+ /*
+ * Due to low fragmentation efforts, we try a little
+ * harder to satisfy high order allocations and only
+ * go OOM for low-order allocations
+ */
+ if (order >= MAX_ORDER/2 && --highorder_retry > 0)
+ goto rebalance;
goto restart;

If order >= MAX_ORDER/2 it doesn't call out_of_memory(). The logic behind it is that we shouldn't go OOM for large-order allocations, because we aren't really OOM. And if we can't satisfy these large allocations then killing processes should have little chance of helping. Mel and I had discussed this privately, agreed, and it is reflected in the comment.

But it's a bit of a behavior change and I didn't want it to go unnoticed. I guess the question is, should existing behavior of going OOM even for large order allocations be maintained? Or is this change a better way, especially in light of the lower fragmentation and increased attempts, like we think it is?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at