From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 21:58:52 +0800
> [SNMP]: Fix SNMP counters with PREEMPT
>
> The SNMP macros use raw_smp_processor_id() in process context
> which is illegal because the process may be preempted and then
> migrated to another CPU.
>
> This patch makes i
On Tue, Dec 18, 2007 at 11:43:44AM +, Gerrit Renker wrote:
>
> It looks as if this work is reaching the cause of the problem, which would
> be good since the problem propagates to all users of such counters (UDP,
> UDP-Lite, and similar MIB counters). So thank you for taking this issue up,
> I
|
| I didn't hear any objections so here is the patch again.
|
| [SNMP]: Fix SNMP counters with PREEMPT
|
I don't feel competent to say whether this is correct, but it seems that
this is going a long way towards resolving older problems with the SNMP
counters.
What I can say is that a year ago,
On Sun, 16 Dec 2007, Herbert Xu wrote:
> If we can get the address of the per-cpu counter against
> some sort of a per-cpu base pointer, e.g., %gs on x86, then
> we can do
>
> incq%gs:(%rax)
>
> where %rax would be the offset with %gs as the base. This would
> obviate the need for the
The cpu alloc patches also fix this issue one way (disabling preempt) or
the other (atomic instruction that does not need disabling of
preeemption).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://v
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 15, 2007 at 07:43:28PM +0100, Ingo Molnar wrote:
> >
> > we could perhaps introduce stat_smp_processor_id(), which signals that
> > the CPU id is used for statistical purposes and does not have to be
> > exact? In any case, your patch looks
On Sat, Dec 15, 2007 at 07:43:28PM +0100, Ingo Molnar wrote:
>
> we could perhaps introduce stat_smp_processor_id(), which signals that
> the CPU id is used for statistical purposes and does not have to be
> exact? In any case, your patch looks good too.
Unfortunately that doesn't work because w
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
> >
> > Never mind, we already have that in local_t and as Alexey correctly
> > points out, USER is still going to be the expensive variant with the
> > preempt_disable (well until BH gets threa
Herbert Xu a écrit :
Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
Never mind, we already have that in local_t and as Alexey correctly
points out, USER is still going to be the expensive variant with the
preempt_disable (well until BH gets threaded). So how about this patch?
I d
Ob Tue, Dec 04, 2007 at 12:17:23AM +1100, Herbert Xu wrote:
>
> Never mind, we already have that in local_t and as Alexey correctly
> points out, USER is still going to be the expensive variant with the
> preempt_disable (well until BH gets threaded). So how about this patch?
I didn't hear any o
On Tue, Dec 04, 2007 at 11:50:55AM +0800, Wang Chen wrote:
>
> > #include
> > #include
> > +#include
>
> It's no need to include smp.h?
We need it for smp_processor_id. Well we needed it before too but
there's probably some implicit inclusion which has made it work.
It's better to declare t
Herbert Xu said the following on 2007-12-3 21:17:
> On Mon, Dec 03, 2007 at 10:54:35PM +1100, Herbert Xu wrote:
> diff --git a/include/net/snmp.h b/include/net/snmp.h
> index ea206bf..9444b54 100644
> --- a/include/net/snmp.h
> +++ b/include/net/snmp.h
> @@ -23,6 +23,7 @@
>
> #include
> #inclu
On Mon, Dec 03, 2007 at 10:54:35PM +1100, Herbert Xu wrote:
>
> Hmm, wasn't someone else talking about a non-atomic version of atomic
> ops lately (i.e., atomic with respect to the local CPU only)? Perhaps
> this is the killer app for it :)
Never mind, we already have that in local_t and as Alexey
On Mon, Dec 03, 2007 at 02:49:12PM +0300, Alexey Kuznetsov wrote:
> On Mon, Dec 03, 2007 at 10:39:35PM +1100, Herbert Xu wrote:
> > So we need to fix this, and whatever the fix is will probably render
> > the BH/USER distinction obsolete.
>
> Hmm, I would think opposite. USER (or generic) is expen
On Mon, Dec 03, 2007 at 10:39:35PM +1100, Herbert Xu wrote:
> So we need to fix this, and whatever the fix is will probably render
> the BH/USER distinction obsolete.
Hmm, I would think opposite. USER (or generic) is expensive variant,
BH is lite. No?
Alexey
--
To unsubscribe from this list: send
On Mon, Dec 03, 2007 at 03:19:35PM +0800, Wang Chen wrote:
>
> System calls should be USER. So change the BH to USER for
> UDP*_INC_STATS_BH().
>
> Signed-off-by: Wang Chen <[EMAIL PROTECTED]>
I've rearragned it so that we the new INC_STATS call is USER in the
first patch. Otherwise it's all in
Herbert Xu said the following on 2007-12-1 9:54:
> On Fri, Nov 30, 2007 at 11:19:49AM +, Gerrit Renker wrote:
>> | csum_copy_err:
>> | - UDP6_INC_STATS_USER(UDP_MIB_INERRORS, is_udplite);
>> | + UDP6_INC_STATS_BH(UDP_MIB_INERRORS, is_udplite);
>> |skb_kill_datagram(sk, skb, flags);
>> |
On Fri, Nov 30, 2007 at 11:19:49AM +, Gerrit Renker wrote:
>
> | csum_copy_err:
> | - UDP6_INC_STATS_USER(UDP_MIB_INERRORS, is_udplite);
> | + UDP6_INC_STATS_BH(UDP_MIB_INERRORS, is_udplite);
> | skb_kill_datagram(sk, skb, flags);
> |
> | if (flags & MSG_DONTWAIT)
> |
> Is it no
Quoting Wang Chen:
| (This patch base on "PATCH 2/3".)
|
| UDP_MIB_INERRORS increment is in different way for IPv4
| and IPv6. For the consistence, change UDP6_INC_STATS_USER
| to UDP6_INC_STATS_BH.
|
| Signed-off-by: Wang Chen <[EMAIL PROTECTED]>
| ---
| udp.c |2 +-
| 1 files changed, 1 in
(This patch base on "PATCH 2/3".)
UDP_MIB_INERRORS increment is in different way for IPv4
and IPv6. For the consistence, change UDP6_INC_STATS_USER
to UDP6_INC_STATS_BH.
Signed-off-by: Wang Chen <[EMAIL PROTECTED]>
---
udp.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2.
20 matches
Mail list logo
