From: Mingming Cao <cmm@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: kiran@scalex86.org, LaurentVivier@wanadoo.fr, sct@redhat.com,
linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] ext3 percpu counter fixes to suppport for more than 2**31 ext3 free blocks counter
Date: Mon, 24 Apr 2006 10:48:32 -0700 [thread overview]
Message-ID: <1145900913.4820.14.camel@dyn9047017069.beaverton.ibm.com> (raw)
In-Reply-To: <20060421150943.2fdc5c4a.akpm@osdl.org>
On Fri, 2006-04-21 at 15:09 -0700, Andrew Morton wrote:
> Mingming Cao <cmm@us.ibm.com> wrote:
> >
> > The following patches are to fix the percpu counter issue support more
> > than 2**31 blocks for ext3, i.e. allow the ext3 free block accounting
> > works with more than 8TB storage.
> >
> > [PATCH 1] - Generic perpcu longlong type counter support: global counter
> > type changed from long to long long. The local counter is still remains
> > 32 bit (long type), so we could avoid doing 64 bit update in most cases.
> > Fixed the percpu_counter_read_positive() to handle the 0 value counter
> > correctly;Add support to initialize the global counter to a value that
> > are greater than 2**32.
>
> I think it would be saner to explicitly specify the size of the field.
> That means using s32 and s64 throughout this code.
>
Agree. Will use s64 in this code. As s32 has the same issue with what we
have(unsigned long) on 32 bit machine today: it is not enough for ext3
to support more than 2**31 free blocks, and also obviously not enough
for 64 bit ext3 that Laurent is working on.
> That'll actually save space on 64-bit machines, where we're presently doing
> alloc_percpu(long) when all we need is alloc_percpu(s32).
>
> We'd need to review all users of this interface to make sure that they
> handle the changed sizes appropriately, too.
I looked at the all users of percpu counter that are currently in
mainline(2.6.17-rc1) and in mm tree(2.6.17-rc1-mm2), they are:
1. ext2 free blocks/inodes/dirs
(int type, to be changed to unsinged long)
2. ext3 free blocks/inodes/dirs
(int type, changing to unsigned long or unsigned long long)
3. nr_files
(currently int type)
4. decnet_memory allocated
(was atomic_t type in mainline, changed to percpu counter type in mm)
5. tcp_memory allocated
(was atomic_t type, changed to percpu counter type in mm tree)
I could be wrong, but I think there will be no effect to change the size
of the global counter from "long" to s64 for above percpu counter users,
except gives the counter more room to grow. Kiran, what do you think?
Did I miss any other users of the perpcu counters?
Mingming
next prev parent reply other threads:[~2006-04-24 17:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-10 17:58 [RFC][PATCH 0/3] ext3 percpu counter fixes to suppport for ext3 unsigned long type free blocks counter Mingming Cao
2006-04-11 17:09 ` Christoph Lameter
2006-04-11 19:01 ` Mingming Cao
2006-04-11 22:20 ` Ravikiran G Thirumalai
2006-04-12 21:28 ` [Ext2-devel] " Mingming Cao
2006-04-12 21:50 ` Andreas Dilger
2006-04-13 19:02 ` Ravikiran G Thirumalai
2006-04-13 22:25 ` Mingming Cao
2006-04-14 0:20 ` Ravikiran G Thirumalai
2006-04-21 14:59 ` [PATCH 1/2] ext3 percpu counter fixes to suppport for more than 2**31 ext3 " Mingming Cao
2006-04-21 22:09 ` Andrew Morton
2006-04-24 17:48 ` Mingming Cao [this message]
2006-04-24 18:26 ` Ravikiran G Thirumalai
2006-04-24 19:13 ` Mingming Cao
2006-04-22 0:56 ` Ravikiran G Thirumalai
2006-04-24 17:49 ` Mingming Cao
2006-04-24 22:51 ` [RESEND][PATCH 1/2] percpu counter data type changes " Mingming Cao
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=1145900913.4820.14.camel@dyn9047017069.beaverton.ibm.com \
--to=cmm@us.ibm.com \
--cc=LaurentVivier@wanadoo.fr \
--cc=akpm@osdl.org \
--cc=ext2-devel@lists.sourceforge.net \
--cc=kiran@scalex86.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).