From: Andreas Dilger <adilger@clusterfs.com>
To: Alex Tomas <bzzz@tmi.comex.ru>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
ext2-devel@lists.sourceforge.net, Andrew Morton <akpm@digeo.com>
Subject: Re: [Ext2-devel] [PATCH] distributed counters for ext2 to avoid group scaning
Date: Sun, 16 Mar 2003 10:44:48 -0700 [thread overview]
Message-ID: <20030316104447.D12806@schatzie.adilger.int> (raw)
In-Reply-To: <m3el5773to.fsf@lexa.home.net>; from bzzz@tmi.comex.ru on Sun, Mar 16, 2003 at 06:01:55PM +0300
On Mar 16, 2003 18:01 +0300, Alex Tomas wrote:
> hi!
>
> ext2 with concurrent balloc/ialloc doesn't maintain global free inodes/blocks
> counters. This is due to badness of spinlocks and atomic_t from big iron's
> viewpoint. therefore, to know these values we should scan all group
> descriptors. there are 81 groups for 10G fs. I believe there is method to
> avoid scaning and decrease memory footprint.
>
> problem:
> 1) we have to maintain something like global counter
> 2) we do not want to use spinlock/atomic because of cache ping-pong badness
> 3) it's possible to fluctuate for some counters
> for example, free blocks counter in ext2
>
> solution:
> lets have some base value of counter and diff value for each cpu.
> every time, someone wants to change (increase/decrease) counter, he
> increases/decreases diff value for current cpu. value of global counter
> may be calculated as sum of base value and all diffs. In order to prevent
> diff overflow, we need sometime to 'resyn' diff with base value. this
> resync needs to be serialized by seqlock. I called it 'distributed counter'.
This sounds like a good idea. I've thought about ways of fixing this
in the past, but hadn't had any good solutions. Unfortunately, we are
still stuck with updating the per-group free blocks/inodes counts, and
since they are modified directly in the buffer heads we can't go changing
the alignments of those fields to match the locks.
> + dcounter_init(&EXT2_SB(sb)->free_blocks_dc, total_free, 1);
> + dcounter_init(&EXT2_SB(sb)->free_inodes_dc,
> + le32_to_cpu (es->s_free_inodes_count), 1);
> +static inline void dcounter_init(struct dcounter *dc, int value, int min)
> +{
> + seqlock_init(&dc->lock);
> + dc->base = value;
> + dc->min = min;
> + memset(dc->diff, 0, sizeof(int) * NR_CPUS);
> +}
So, why is it that the minimum free blocks/inodes is 1?
> +struct dcounter {
> + int base;
> + int min;
> + int diff[NR_CPUS];
> + seqlock_t lock;
> +};
For a generic struct, it probably makes more sense to make these fields
"long" instead of "int".
Also, while your goal is to reduce cache ping-pong between CPUs, we will
now have cache ping-pong for the "diff" array. We need to do per-cpu
values or make each value cacheline aligned to avoid ping-pong.
Just for sanity's sake, it would be good to call these fields something
other than "min" and "lock", since that makes life just hell with tags
(it always bugs me when structs have fields called list_head, list_entry,
page, inode, etc).
Maybe something like "dc_min", "dc_lock", etc. would be much nicer?
The same goes for the fields in the block group info - it would be nice
if they had a "bgi_" prefix.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
next prev parent reply other threads:[~2003-03-16 17:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-16 15:01 Alex Tomas
2003-03-16 17:44 ` Andreas Dilger [this message]
2003-03-16 21:55 ` [Ext2-devel] " Alex Tomas
2003-03-17 15:11 ` Matthew Wilcox
2003-03-17 15:09 ` Alex Tomas
2003-03-17 15:27 ` Matthew Wilcox
2003-03-17 15:25 ` Alex Tomas
2003-03-17 20:23 ` Andrew Morton
2003-03-17 20:27 ` Matthew Wilcox
2003-03-17 20:40 ` Alex Tomas
2003-03-17 9:37 ` William Lee Irwin III
2003-03-17 9:48 ` William Lee Irwin III
2003-03-17 10:41 ` Alex Tomas
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=20030316104447.D12806@schatzie.adilger.int \
--to=adilger@clusterfs.com \
--cc=akpm@digeo.com \
--cc=bzzz@tmi.comex.ru \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®