From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Wu Fengguang <wfg@mail.ustc.edu.cn>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH 04/16] radix-tree: look-aside cache
Date: Thu, 10 Nov 2005 10:31:09 +1100 [thread overview]
Message-ID: <437286BD.4000107@yahoo.com.au> (raw)
In-Reply-To: <20051109141448.974675000@localhost.localdomain>
Wu Fengguang wrote:
> This introduces a set of lookup functions to radix tree for the read-ahead
> logic. Other access patterns with high locality may also benefit from them.
>
Hi Wu,
Does this cache add much performance compared with simple repeated
lookups? If the access patterns are highly local, the top of the
radix tree should be in cache.
I worry that it is a fair bit of extra complexity for something
slow like the IO path - however I haven't looked at how you use the
cache.
> Most of them are best inlined, so some macros/structs in .c are moved into .h.
>
I would not inline them. You'd find that the extra icache misses
that costs outweighs the improvements for larger functions.
> +
> +struct radix_tree_node {
> + unsigned int count;
> + void *slots[RADIX_TREE_MAP_SIZE];
> + unsigned long tags[RADIX_TREE_TAGS][RADIX_TREE_TAG_LONGS];
> +};
> +
Would be much nicer if this weren't declared in the header file, so
people don't start trying to use the nodes where they shouldn't.
This ought to be possible after uninlining a couple of things.
> struct radix_tree_root {
> unsigned int height;
> gfp_t gfp_mask;
> struct radix_tree_node *rnode;
> };
>
> +/*
> + * Support access patterns with strong locality.
> + */
Do you think you could provide a simple 'use case' for an overview
of how you use the cache and what calls to make?
> +struct radix_tree_cache {
> + unsigned long first_index;
> + struct radix_tree_node *tree_node;
> +};
> +
> +static inline void radix_tree_cache_init(struct radix_tree_cache *cache)
> +{
> + cache->first_index = 0x77;
> + cache->tree_node = NULL;
> +}
> +
> +static inline int radix_tree_cache_size(struct radix_tree_cache *cache)
> +{
> + return RADIX_TREE_MAP_SIZE;
> +}
> +
> +static inline int radix_tree_cache_count(struct radix_tree_cache *cache)
> +{
> + if (cache->first_index != 0x77)
> + return cache->tree_node->count;
> + else
> + return 0;
> +}
> +
What's 0x77 for? And what happens if your cache gets big enough that
the first index is 0x77?
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2005-11-09 23:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-09 13:49 [PATCH 00/16] Adaptive read-ahead V7 Wu Fengguang
2005-11-09 13:49 ` [PATCH 01/16] mm: delayed page activation Wu Fengguang
2005-11-10 0:21 ` Nick Piggin
2005-11-10 3:15 ` Wu Fengguang
2005-11-10 9:17 ` Peter Zijlstra
2005-11-10 10:30 ` Wu Fengguang
2005-11-09 13:49 ` [PATCH 02/16] mm: balance page aging between zones Wu Fengguang
2005-11-09 13:49 ` [PATCH 03/16] radixtree: sync with mainline Wu Fengguang
2005-11-09 13:49 ` [PATCH 04/16] radix-tree: look-aside cache Wu Fengguang
2005-11-09 23:31 ` Nick Piggin [this message]
2005-11-10 5:25 ` Wu Fengguang
2005-11-10 6:50 ` Nick Piggin
2005-11-10 8:30 ` Wu Fengguang
2005-11-18 11:25 ` Wu Fengguang
2005-11-18 12:12 ` Wu Fengguang
2005-11-09 13:49 ` [PATCH 05/16] readahead: some preparation Wu Fengguang
2005-11-18 7:46 ` 2.6.15-rc1-mm2 Andrew Morton
2005-11-18 8:56 ` 2.6.15-rc1-mm2 Benoit Boissinot
2005-11-18 9:04 ` 2.6.15-rc1-mm2 Andrew Morton
2005-11-18 9:13 ` 2.6.15-rc1-mm2 Benoit Boissinot
2005-11-18 13:43 ` 2.6.15-rc1-mm2 Rafael J. Wysocki
2005-11-18 10:10 ` 2.6.15-rc1-mm2 Mauro Carvalho Chehab
2005-11-18 10:55 ` 2.6.15-rc1-mm2 Wu Fengguang
2005-11-18 11:29 ` 2.6.15-rc1-mm2 Andy Whitcroft
2005-11-18 16:29 ` 2.6.15-rc1-mm2 Michael Krufky
2005-11-20 0:23 ` 2.6.15-rc1-mm2 Michal Piotrowski
2005-11-20 8:04 ` 2.6.15-rc1-mm2 Hugh Dickins
2005-11-20 12:53 ` 2.6.15-rc1-mm2 Michal Piotrowski
2005-11-09 13:49 ` [PATCH 06/16] readahead: call scheme Wu Fengguang
2005-11-09 13:49 ` [PATCH 07/16] readahead: tunable parameters Wu Fengguang
2005-11-09 13:49 ` [PATCH 08/16] readahead: state based method Wu Fengguang
2005-11-09 13:49 ` [PATCH 09/16] readahead: context " Wu Fengguang
2005-11-09 13:49 ` [PATCH 10/16] readahead: other methods Wu Fengguang
2005-11-09 13:49 ` [PATCH 11/16] readahead: mandatory thrashing protection Wu Fengguang
2005-11-09 13:49 ` [PATCH 12/16] readahead: events accounting Wu Fengguang
2005-11-09 13:49 ` [PATCH 13/16] readahead: page aging accounting Wu Fengguang
2005-11-09 13:49 ` [PATCH 14/16] readahead: laptop mode support Wu Fengguang
2005-11-09 13:49 ` [PATCH 15/16] readahead: disable look-ahead for loopback file Wu Fengguang
2005-11-09 13:49 ` [PATCH 16/16] io: reduce lantency Wu Fengguang
2005-11-09 20:39 ` [PATCH 00/16] Adaptive read-ahead V7 Christoph Lameter
2005-11-10 10:19 ` Wu Fengguang
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=437286BD.4000107@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