Re: [PATCH 3/5] hugetlb: try to search again if it is really needed

[Xiao Guangrong]

Hi Andrew,

Thanks for your review!

On 02/02/2012 06:43 AM, Andrew Morton wrote:

> On Fri, 13 Jan 2012 19:45:45 +0800
> Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> wrote:
> 
>> Search again only if some holes may be skipped in the first time
>>
>> Signed-off-by: Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx>
>> ---
>>  arch/x86/mm/hugetlbpage.c |    8 ++++----
>>  1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
>> index e12debc..6bf5735 100644
>> --- a/arch/x86/mm/hugetlbpage.c
>> +++ b/arch/x86/mm/hugetlbpage.c
>> @@ -309,9 +309,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
>>  	struct hstate *h = hstate_file(file);
>>  	struct mm_struct *mm = current->mm;
>>  	struct vm_area_struct *vma;
>> -	unsigned long base = mm->mmap_base, addr = addr0;
>> +	unsigned long base = mm->mmap_base, addr = addr0, start_addr;
> 
> grr.  The multiple-definitions-per-line thing is ugly, makes for more
> patch conflicts and reduces opportunities to add useful comments.


Yes, thanks.

>>  try_again:
>> +	start_addr = mm->free_area_cache;
>> +
>>  	/* make sure it can fit in the remaining address space */
>>  	if (mm->free_area_cache < len)
>>  		goto fail;
>> @@ -357,10 +358,9 @@ fail:
>>  	 * if hint left us with no space for the requested
>>  	 * mapping then try again:
>>  	 */
>> -	if (first_time) {
>> +	if (start_addr != base) {
>>  		mm->free_area_cache = base;
>>  		largest_hole = 0;
>> -		first_time = 0;
>>  		goto try_again;
> 
> The code used to retry a single time.  With this change the retrying is
> potentially infinite.  What is the reason for this change?  What is the
> potential for causing a lockup?
> 

Actually, it is not infinite, after retry, we set "mm->free_area_cache = base",
"start_addr" will set to "base" in the second search, so the condition of
"goto try_again" will be unsatisfied.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/