From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Fengguang Wu <wfg@mail.ustc.edu.cn>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] radixtree: introduce radix_tree_scan_hole()
Date: Mon, 23 Jul 2007 17:58:02 +1000 [thread overview]
Message-ID: <46A45F8A.5060600@yahoo.com.au> (raw)
In-Reply-To: <384993020.08966@ustc.edu.cn>
Fengguang Wu wrote:
> Introduce radix_tree_scan_hole(root, index, max_scan) to scan radix tree
> for the first hole. It will be used in interleaved readahead.
>
> The implementation is dumb and obviously correct.
> It can help debug(and document) the possible smart one in future.
Reasonable function to want. Is radix_tree_scan_hole the best name?
What about radix_tree_next_hole or _find_next_hole? (Andrew, any
suggestions?)
>
> Cc: Nick Piggin <nickpiggin@yahoo.com.au>
> Signed-off-by: Fengguang Wu <wfg@mail.ustc.edu.cn>
> ---
>
> include/linux/radix-tree.h | 2 ++
> lib/radix-tree.c | 34 ++++++++++++++++++++++++++++++++++
> 2 files changed, 36 insertions(+)
>
> --- linux-2.6.22-rc6-mm1.orig/include/linux/radix-tree.h
> +++ linux-2.6.22-rc6-mm1/include/linux/radix-tree.h
> @@ -155,6 +155,8 @@ void *radix_tree_delete(struct radix_tre
> unsigned int
> radix_tree_gang_lookup(struct radix_tree_root *root, void **results,
> unsigned long first_index, unsigned int max_items);
> +unsigned long radix_tree_scan_hole(struct radix_tree_root *root,
> + unsigned long index, unsigned long max_scan);
> int radix_tree_preload(gfp_t gfp_mask);
> void radix_tree_init(void);
> void *radix_tree_tag_set(struct radix_tree_root *root,
> --- linux-2.6.22-rc6-mm1.orig/lib/radix-tree.c
> +++ linux-2.6.22-rc6-mm1/lib/radix-tree.c
> @@ -601,6 +601,40 @@ int radix_tree_tag_get(struct radix_tree
> EXPORT_SYMBOL(radix_tree_tag_get);
> #endif
>
> +static unsigned long
> +radix_tree_scan_hole_dumb(struct radix_tree_root *root,
> + unsigned long index, unsigned long max_scan)
> +{
> + unsigned long i;
> +
> + for (i = 0; i < max_scan; i++) {
> + if (!radix_tree_lookup(root, index))
> + break;
> + if (++index == 0)
> + break;
Minor nit: I think it is preferred to have index++; on its own line.
> + }
> +
> + return index;
> +}
> +
> +/**
> + * radix_tree_scan_hole - scan for hole
> + * @root: radix tree root
> + * @index: index key
> + * @max_scan: advice on max items to scan (it may scan a little more)
> + *
> + * Scan forward from @index for a hole/empty item, stop when
> + * - hit hole
> + * - wrap-around to index 0
> + * - @max_scan or more items scanned
> + */
Some suggestions on the comment:
/**
* radix_tree_next_hole - find the next hole (not-present entry)
* @root: radix tree root
* @index: index key
* @max_scan: maximum range to search
*
* Search the set [index, min(index+max_scan-1, MAX_INDEX)] for the lowest
* indexed hole.
*
* Returns: the index of the hole if found, otherwise returns an index
* outside of the set specified (in which case 'return - index >= max_scan'
* will be true).
*
* radix_tree_next_hole may be called under rcu_read_lock. However, like
* radix_tree_gang_lookup, this will not atomically search a snapshot of the
* tree at a single point in time. For example, if a hole is created at index
* 5, then subsequently a hole is created at index 10, radix_tree_next_hole
* covering both indexes may return 10 if called under rcu_read_lock.
*/
> +unsigned long radix_tree_scan_hole(struct radix_tree_root *root,
> + unsigned long index, unsigned long max_scan)
> +{
> + return radix_tree_scan_hole_dumb(root, index, max_scan);
> +}
> +EXPORT_SYMBOL(radix_tree_scan_hole);
Don't do this scan_hole_dumb thing. Just implement it in place.
--
SUSE Labs, Novell Inc.
next prev parent reply other threads:[~2007-07-23 7:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070721044300.909424569@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 0/7] readahead cleanups and interleaved readahead take 3 Fengguang Wu
[not found] ` <20070721044346.554186594@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 1/7] readahead: compacting file_ra_state Fengguang Wu
[not found] ` <20070721044346.687587063@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 2/7] readahead: mmap read-around simplification Fengguang Wu
[not found] ` <20070721044346.824927556@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 3/7] readahead: combine file_ra_state.prev_index/prev_offset into prev_pos Fengguang Wu
[not found] ` <20070721044347.008643456@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 4/7] readahead: remove several readahead macros Fengguang Wu
[not found] ` <20070721044347.111061630@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 5/7] readahead: remove the limit max_sectors_kb imposed on max_readahead_kb Fengguang Wu
[not found] ` <20070721044347.250839328@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 6/7] radixtree: introduce radix_tree_scan_hole() Fengguang Wu
2007-07-21 5:48 ` Andrew Morton
[not found] ` <20070721063629.GA7013@mail.ustc.edu.cn>
2007-07-21 6:36 ` Fengguang Wu
2007-07-23 7:58 ` Nick Piggin [this message]
[not found] ` <20070723080405.GA7420@mail.ustc.edu.cn>
2007-07-23 8:04 ` Fengguang Wu
[not found] ` <20070723081209.GA12393@mail.ustc.edu.cn>
2007-07-23 8:12 ` Fengguang Wu
[not found] ` <20070721044347.388744012@mail.ustc.edu.cn>
2007-07-21 4:43 ` [PATCH 7/7] readahead: basic support of interleaved reads Fengguang Wu
2007-07-21 7:24 ` Rusty Russell
[not found] ` <20070721075744.GA10790@mail.ustc.edu.cn>
2007-07-21 7:57 ` Fengguang Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46A45F8A.5060600@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wfg@mail.ustc.edu.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox