linux-kernel - Re: [PATCH] lib : provide a more precise radix_tree_gang_lookup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4A1CEE3F.6030504@gmail.com>
Date:	Wed, 27 May 2009 15:39:43 +0800
From:	Huang Shijie <shijie8@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	cl@...ux-foundation.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lib : provide a more precise radix_tree_gang_lookup_slot


>> diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
>> index 355f6e8..03e25f4 100644
>> --- a/include/linux/radix-tree.h
>> +++ b/include/linux/radix-tree.h
>> @@ -164,7 +164,8 @@ radix_tree_gang_lookup(struct radix_tree_root *root, void **results,
>>  			unsigned long first_index, unsigned int max_items);
>>  unsigned int
>>  radix_tree_gang_lookup_slot(struct radix_tree_root *root, void ***results,
>> -			unsigned long first_index, unsigned int max_items);
>> +			unsigned long first_index, unsigned int max_items,
>> +			int contig);
>>     
>
> Variable `contig' could have the type `bool'.  Did you consider and
> reject that option, or just didn't think of it?
>
>
>   
Yes, type `bool' is better.
>> ...
>> +			if (contig)
>> +				goto out;
>> +
>> +		} else if (contig) {
>> +			index--;
>> +			goto out;
>> +
>> +		if (contig) {
>> +			if (slots_found == 0)
>> +				break;
>> +			if (next_index & RADIX_TREE_MAP_MASK)
>> +				break;
>> +		}
>> -				(void ***)pages, start, nr_pages);
>> +				(void ***)pages, start, nr_pages, 0);
>> -				(void ***)pages, index, nr_pages);
>> +				(void ***)pages, index, nr_pages, 1);
>>     
>
> The patch adds cycles in some cases and saves them in others.
>
> Does the saving exceed the adding?  How do we know that the patch is a
> net benefit?
>
>   

Assume that:
    f0 = called frequency of find_get_pages() (contig == 0)
    f1 = called frequency of find_get_pages_contig() (contig == 1)

The primary user of find_get_pages() is ->writepage[s] of some file 
systems such as ext4.
( I think the shmem_lock() ,truncate() run occasionally which also call it.)

The primary user of find_get_pages_contig()  is also the ->writepage[s] 
of some filesystem
such as afs.( I am not sure whether btrfs is also the main user of it )

   So if (f0 nearly equal f1)
         cycles saving >> cycles adding

  __lookup() saves much cycles when there are holes and the contig==1.
     



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