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

[Joel Schopp <jschopp@austin.ibm.com>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/