From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Tejun Heo <tj@kernel.org>, Shaohua Li <shaohua.li@intel.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH] percpu: preemptless __per_cpu_counter_add
Date: Thu, 28 Apr 2011 17:48:46 +0200 [thread overview]
Message-ID: <1304005726.3360.69.camel@edumazet-laptop> (raw)
In-Reply-To: <alpine.DEB.2.00.1104281017240.16323@router.home>
Le jeudi 28 avril 2011 A 10:22 -0500, Christoph Lameter a A(C)crit :
> On Thu, 28 Apr 2011, Tejun Heo wrote:
>
> > It seems like we can split hairs all day long about the similarities
> > and differences with atomics, so let's forget about atomics for now.
>
> Ok good idea. So you accept that per cpu counters are inevitably fuzzy and
> that the result cannot be relied upon in the same way as on atomics?
>
> > I don't like any update having possibility of causing @batch jumps in
> > _sum() result. That severely limits the usefulness of hugely
> > expensive _sum() and the ability to scale @batch. Not everything in
> > the world is vmstat. Think about other _CURRENT_ use cases in
> > filesystems.
>
> Of course you can cause jumps > batch. You are looping over 8 cpus and
> have done cpu 1 and 2 already. Then cpu 1 adds batch-1 to the local per
> cpu counter. cpu 2 increments its per cpu counter. When _sum returns we
> have deviation of batch.
>
> In the worst case the deviation can increase to (NR_CPUS - 1) * (batch
> -1). That is for the current code!!!
>
> The hugely expensive _sum() is IMHO pretty useless given the above. It is
> a function that is called with the *hope* of getting a more accurate
> result.
>
> The only way to reduce the fuzziness is by reducing batch. But then you
> dont need the _sum function.
>
> Either that or you need additional external synchronization by the
> subsystem that prevents updates.
>
>
We could add a seqcount (shared), and increment it each time one cpu
changes global count.
_sum() could get an additional parameter, the max number of allowed
changes during _sum() run.
If _sum() notices seqcount was changed too much, restart the loop.
s64 __percpu_counter_sum(struct percpu_counter *fbc, unsigned maxfuzzy)
{
s64 ret;
unsigned int oldseq, newseq;
int cpu;
restart:
oldseq = fbc->seqcount;
smp_rmb();
ret = fbc->count;
for_each_online_cpu(cpu) {
s32 *pcount = per_cpu_ptr(fbc->counters, cpu);
ret += *pcount;
}
smp_rmb()
newseq = fbc->count;
if (newseq - oldseq >= maxfuzzy)
goto restart;
return ret;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-04-28 15:48 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-13 14:45 Christoph Lameter
2011-04-13 16:49 ` Christoph Lameter
2011-04-13 18:56 ` Tejun Heo
2011-04-13 20:22 ` [PATCH] " Christoph Lameter
2011-04-13 21:50 ` Tejun Heo
2011-04-13 22:17 ` Christoph Lameter
2011-04-13 22:23 ` Christoph Lameter
2011-04-13 23:55 ` Tejun Heo
2011-04-14 2:00 ` Eric Dumazet
2011-04-14 2:14 ` Eric Dumazet
2011-04-14 21:10 ` Christoph Lameter
2011-04-14 21:15 ` Tejun Heo
2011-04-15 17:37 ` Christoph Lameter
2011-04-15 18:27 ` Tejun Heo
2011-04-15 19:43 ` Christoph Lameter
2011-04-15 23:52 ` Tejun Heo
2011-04-18 14:38 ` Christoph Lameter
2011-04-21 14:43 ` Tejun Heo
2011-04-21 14:58 ` Tejun Heo
2011-04-21 17:50 ` Christoph Lameter
2011-04-21 18:01 ` Tejun Heo
2011-04-21 18:20 ` Christoph Lameter
2011-04-21 18:37 ` Tejun Heo
2011-04-21 18:54 ` Christoph Lameter
2011-04-21 19:08 ` Tejun Heo
2011-04-22 2:33 ` Shaohua Li
2011-04-26 12:10 ` Tejun Heo
2011-04-26 19:02 ` Hugh Dickins
2011-04-27 10:28 ` Tejun Heo
2011-04-27 5:43 ` Shaohua Li
2011-04-27 10:20 ` Tejun Heo
2011-04-28 3:28 ` Shaohua Li
2011-04-28 10:09 ` Tejun Heo
2011-04-28 14:11 ` Christoph Lameter
2011-04-28 14:23 ` Tejun Heo
2011-04-28 14:30 ` Tejun Heo
2011-04-28 14:58 ` Christoph Lameter
2011-04-28 14:42 ` Christoph Lameter
2011-04-28 14:44 ` Tejun Heo
2011-04-28 14:52 ` Christoph Lameter
2011-04-28 14:56 ` Tejun Heo
2011-04-28 15:05 ` Christoph Lameter
2011-04-28 15:12 ` Tejun Heo
2011-04-28 15:22 ` Christoph Lameter
2011-04-28 15:31 ` Tejun Heo
2011-04-28 15:40 ` Tejun Heo
2011-04-28 15:47 ` Christoph Lameter
2011-04-28 15:48 ` Eric Dumazet [this message]
2011-04-28 15:59 ` Eric Dumazet
2011-04-28 16:17 ` Christoph Lameter
2011-04-28 16:35 ` Eric Dumazet
2011-04-28 16:52 ` Christoph Lameter
2011-04-28 16:59 ` Eric Dumazet
2011-04-29 8:52 ` Tejun Heo
2011-04-29 8:32 ` Shaohua Li
2011-04-29 8:19 ` Shaohua Li
2011-04-29 8:44 ` Tejun Heo
2011-04-29 14:02 ` Christoph Lameter
2011-04-29 14:03 ` Christoph Lameter
2011-04-29 14:18 ` Tejun Heo
2011-04-29 14:25 ` Christoph Lameter
2011-04-29 14:43 ` Tejun Heo
2011-04-29 14:55 ` Christoph Lameter
2011-05-05 4:08 ` Shaohua Li
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=1304005726.3360.69.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=linux-mm@kvack.org \
--cc=shaohua.li@intel.com \
--cc=tj@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