Re: [PATCH] lib : provide a more precise radix_tree_gang_lookup_slot

[Huang Shijie]

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