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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
