From: Mingming Cao <cmm@us.ibm.com>
To: Ravikiran G Thirumalai <kiran@scalex86.org>
Cc: Christoph Lameter <clameter@sgi.com>,
akpm@osdl.org, Laurent Vivier <Laurent.Vivier@bull.net>,
linux-kernel@vger.kernel.org,
ext2-devel <ext2-devel@lists.sourceforge.net>,
linux-fsdevel@vger.kernel.org
Subject: Re: [Ext2-devel] Re: [RFC][PATCH 0/3] ext3 percpu counter fixes to suppport for ext3 unsigned long type free blocks counter
Date: Wed, 12 Apr 2006 14:28:35 -0700 [thread overview]
Message-ID: <1144877315.3722.26.camel@dyn9047017067.beaverton.ibm.com> (raw)
In-Reply-To: <20060411222012.GA5007@localhost.localdomain>
On Tue, 2006-04-11 at 15:20 -0700, Ravikiran G Thirumalai wrote:
> On Tue, Apr 11, 2006 at 12:01:13PM -0700, Mingming Cao wrote:
> > On Tue, 2006-04-11 at 10:09 -0700, Christoph Lameter wrote:
> > > On Mon, 10 Apr 2006, Mingming Cao wrote:
> > >
> > > > Here are the proposed patches to allow the ext3 free block accounting
> > > > works with more than 8TB storage.
> > >
> > > Umm.. This is an issue on 32 bit platforms only. 64bit platforms x86_64,
> > > ia64 etc do not need this. Would you make it arch specific?
> >
> > Yes, make sense. I will update my patch soon. Thanks.
>
I was thinking something like this:
+void percpu_counter_mod_ul(struct percpu_counter *fbc, long amount)
+{
+ preempt_disable();
+ __percpu_counter_mod(fbc, amount, BITS_PER_LONG<=32);
+ preempt_enable();
+}
+EXPORT_SYMBOL(percpu_counter_mod_ul);
where the check for unsigned long overflow is only turned on 32 bit
platforms.
> Or make the counter s64? so that it stays 64 bit on all arches?
>
Well, don't we have the problem : 64 bit counter add/dec/update is not
always atomic on all 32 bit platforms? There are risk that we will get
bogus global value.
> OR
> why not change the global per-cpu counter type to unsigned long (as we
> discussed earlier), so we don't need the extra "ul" flags and interfaces,
> and all arches get a standard unsigned long return type?
> We could also
> do away with percpu_read_positive then no? The applications for per-cpu
> counters is going to be upcounters always methinks...
>
yeah...I am not so happy with the extra "ul" checking flags either. But
as you have mentioned before, the signed global counter type is there
for some cases when the global counter becomes temporally negative
( although the counter in real life should always positive). What should
we do if the global counter is a unsigned value, was initialized to 0,
and now we add -5 to it(-5 is from one local counter, then we will get a
bogus big value)?
ext3 free blocks counter is always initialized to a big positive value
so I doubt above concern is a real issue for ext3. Perhaps you thought
this through that it's okay to change the global counter to unsigned
long for other applications of PCP counters?
Thanks,
Mingming
next prev parent reply other threads:[~2006-04-12 21:28 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 ` Mingming Cao [this message]
2006-04-12 21:50 ` [Ext2-devel] " 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
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=1144877315.3722.26.camel@dyn9047017067.beaverton.ibm.com \
--to=cmm@us.ibm.com \
--cc=Laurent.Vivier@bull.net \
--cc=akpm@osdl.org \
--cc=clameter@sgi.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=kiran@scalex86.org \
--cc=linux-fsdevel@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).