From: Eric Dumazet <dada1@cosmosbay.com>
To: Ravikiran G Thirumalai <kiran@scalex86.org>
Cc: Andrew Morton <akpm@osdl.org>,
davem@davemloft.net, linux-kernel@vger.kernel.org,
shai@scalex86.org, netdev@vger.kernel.org,
pravins@calsoftinc.com
Subject: Re: [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated
Date: Sat, 28 Jan 2006 08:19:12 +0100 [thread overview]
Message-ID: <43DB1AF0.8040108@cosmosbay.com> (raw)
In-Reply-To: <20060128045248.GA3584@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]
Ravikiran G Thirumalai a écrit :
> On Sat, Jan 28, 2006 at 01:35:03AM +0100, Eric Dumazet wrote:
>> Eric Dumazet a écrit :
>>> Andrew Morton a écrit :
>>>> Eric Dumazet <dada1@cosmosbay.com> wrote:
>>>
>>> long percpu_counter_read_accurate(struct percpu_counter *fbc)
>>> {
>>> long res = 0;
>>> int cpu;
>>> atomic_long_t *pcount;
>>>
>>> for_each_cpu(cpu) {
>>> pcount = per_cpu_ptr(fbc->counters, cpu);
>>> /* dont dirty cache line if not necessary */
>>> if (atomic_long_read(pcount))
>>> res += atomic_long_xchg(pcount, 0);
> ---------------------------> (A)
>>> }
>
>> atomic_long_add(res, &fbc->count);
> ---------------------------> (B)
>> res = atomic_long_read(&fbc->count);
>>
>>> return res;
>>> }
>
> The read is still theoritically FBC_BATCH * NR_CPUS inaccurate no?
> What happens when other cpus update their local counters at (A) and (B)?
Well, after atomic_read(&some_atomic) or percpu_counter_read_accurate(&s) the
'value' you got may be inaccurate by whatever... You cannot 'freeze the
atomic / percpu_counter and gets its accurate value'. All you can do is
'atomically add/remove some value from this counter (atomic or percpu_counter))
See percpu_counter_read_accurate() as an attempt to collect all local offset
(and atomically set them to 0) and atomically reajust the central fbc->count
to with the sum of all these offsets. Kind of a consolidation that might be
driven by a user request (read /proc/sys/...) or a periodic timer.
>
> (I am hoping we don't need percpu_counter_read_accurate anywhere yet and
> this is just demo ;). I certainly don't want to go on all cpus for read /
> add cmpxchg on the write path for the proto counters that started this
> discussion)
As pointed by Andrew (If you decode carefully its short sentences :) ), all
you really need is atomic_long_xchg() (only in slow path), and
atomic_long_{read/add} in fast path)
Eric
[-- Attachment #2: functions --]
[-- Type: text/plain, Size: 1050 bytes --]
struct percpu_counter {
atomic_long_t count;
atomic_long_t *counters;
};
#ifdef CONFIG_SMP
void percpu_counter_mod(struct percpu_counter *fbc, long amount)
{
long new;
atomic_long_t *pcount;
pcount = per_cpu_ptr(fbc->counters, get_cpu());
new = atomic_long_read(pcount) + amount;
if (new >= FBC_BATCH || new <= -FBC_BATCH) {
new = atomic_long_xchg(pcount, 0) + amount;
if (new)
atomic_long_add(new, &fbc->count);
} else
atomic_long_add(amount, pcount);
put_cpu();
}
EXPORT_SYMBOL(percpu_counter_mod);
long percpu_counter_read_accurate(struct percpu_counter *fbc)
{
long res = 0;
int cpu;
atomic_long_t *pcount;
for_each_cpu(cpu) {
pcount = per_cpu_ptr(fbc->counters, cpu);
/* dont dirty cache line if not necessary */
if (atomic_long_read(pcount))
res += atomic_long_xchg(pcount, 0);
}
atomic_long_add(res, &fbc->count);
return atomic_long_read(&fbc->count);
}
EXPORT_SYMBOL(percpu_counter_read_accurate);
#endif /* CONFIG_SMP */
next prev parent reply other threads:[~2006-01-28 7:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-26 18:56 [patch 0/4] net: Percpufy frequently used variables on struct proto Ravikiran G Thirumalai
2006-01-26 18:59 ` [patch 1/4] net: Percpufy frequently used variables -- add percpu_counter_mod_bh Ravikiran G Thirumalai
2006-01-26 19:02 ` [patch 2/4] net: Percpufy frequently used variables -- struct proto.memory_allocated Ravikiran G Thirumalai
2006-01-27 9:01 ` Eric Dumazet
2006-01-26 19:03 ` [patch 3/4] net: Percpufy frequently used variables -- proto.sockets_allocated Ravikiran G Thirumalai
2006-01-27 8:53 ` Eric Dumazet
2006-01-27 19:52 ` Ravikiran G Thirumalai
2006-01-27 20:16 ` Andrew Morton
2006-01-27 22:30 ` Eric Dumazet
2006-01-27 22:50 ` Ravikiran G Thirumalai
2006-01-27 23:21 ` Eric Dumazet
2006-01-28 0:40 ` Ravikiran G Thirumalai
2006-01-27 22:44 ` Ravikiran G Thirumalai
2006-01-27 22:58 ` Eric Dumazet
2006-01-27 23:16 ` Andrew Morton
2006-01-28 0:28 ` Eric Dumazet
2006-01-28 0:35 ` Eric Dumazet
2006-01-28 4:52 ` Ravikiran G Thirumalai
2006-01-28 7:19 ` Eric Dumazet [this message]
2006-01-28 0:43 ` Andrew Morton
2006-01-28 1:10 ` Eric Dumazet
2006-01-28 1:18 ` Andrew Morton
2006-01-29 0:44 ` Benjamin LaHaise
2006-01-29 0:55 ` Andrew Morton
2006-01-29 1:19 ` Benjamin LaHaise
2006-01-29 1:29 ` Andrew Morton
2006-01-29 1:45 ` Kyle McMartin
2006-01-29 5:38 ` Andi Kleen
2006-01-29 6:54 ` Eric Dumazet
2006-01-29 19:52 ` Benjamin LaHaise
2006-01-27 23:01 ` Andrew Morton
2006-01-27 23:08 ` Andrew Morton
2006-01-28 0:01 ` Ravikiran G Thirumalai
2006-01-28 0:26 ` Andrew Morton
2006-02-03 3:05 ` Ravikiran G Thirumalai
2006-02-03 3:16 ` Andrew Morton
2006-02-03 19:37 ` Ravikiran G Thirumalai
2006-02-03 20:13 ` Andrew Morton
2006-01-26 19:05 ` [patch 4/4] net: Percpufy frequently used variables -- proto.inuse Ravikiran G Thirumalai
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=43DB1AF0.8040108@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=kiran@scalex86.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pravins@calsoftinc.com \
--cc=shai@scalex86.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.