Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]snmp6\s+64\-bit\s+counter\s+support\s+in\s+proc\.c\s*$/: 48 ]

Total 48 documents matching your query.

1. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: rle@xxxxxxxxxx>
Date: Wed, 14 Jan 2004 14:52:51 -0800
This is the new patch against 2.6.1 kernel. Thanks Shirley Ma IBM Linux Technology Center Attachment: linux-2.6.1-ipv6mib2-64.patch Description: Text Data
/archives/netdev/2004-01/msg00250.html (9,697 bytes)

2. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: 明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Thu, 15 Jan 2004 00:57:29 -0800
I am personally fine with this patch, but I do believe some folks might find it controversial (for whatever reason) to move all of these stats over to 64-bits. So I'm going to let this sit for anothe
/archives/netdev/2004-01/msg00280.html (9,817 bytes)

3. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: yoshfuji@xxxxxxxxxxxxxx>
Date: Wed, 21 Jan 2004 11:45:30 -0800
objections they may have. Did you hear different voices? If not could you please check in this patch? I am going to submit another patch about new IPv6 MIBs system & interface statistics counters fo
/archives/netdev/2004-01/msg00453.html (9,259 bytes)

4. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: Sorensen <jes@xxxxxxxxxxxxxxxxxx>
Date: Thu, 22 Jan 2004 05:27:47 +0900 (JST)
I'm not against holding in u64, but I rebember that Linus did not liked that. Is it okay? BTW, diff -urN linux-2.6.1/net/ipv6/proc.c linux-2.6.1-ipv6mib2-64/net/ipv6/proc.c struct snmp6_item { char *
/archives/netdev/2004-01/msg00454.html (11,230 bytes)

5. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: ph Hellwig <hch@xxxxxx>
Date: Wed, 21 Jan 2004 14:05:35 -0800
No objections, and I am fine with the change as well. However, I think I will defer it as 2.6.x has a lot of changes in it already. Definitely next release.
/archives/netdev/2004-01/msg00456.html (9,666 bytes)

6. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: k@xxxxxxx>
Date: Wed, 21 Jan 2004 15:44:54 -0800
Thanks for the input. I will fix it. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX: (503) 578-3228
/archives/netdev/2004-01/msg00458.html (9,534 bytes)

7. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: xxxxxxxx>
Date: Thu, 22 Jan 2004 21:26:51 +0300 (MSK)
Here is a little warning. It will give corrupt values on 32 bit archs when update with 32 bit overflow happens while value is folded. To do 64 bit arithmetics you need either to serialize reader wrt
/archives/netdev/2004-01/msg00476.html (9,682 bytes)

8. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: Hen <shmulik.hen@xxxxxxxxx>
Date: Thu, 22 Jan 2004 14:10:26 -0800
The most portable and simple algorithm to solve this on the reader side is (and I recommend we don't special case this on 64-bit platforms just to get wider testing): u32 high, low1, low2; do { low1
/archives/netdev/2004-01/msg00478.html (10,351 bytes)

9. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: n <shmulik.hen@xxxxxxxxx>
Date: Thu, 22 Jan 2004 13:18:49 -0800
That is a good point you raised, we don't want to read the counter while the writer might change and overflow of one word can result in a really corrupt value. If 64bit counters is a good idea to im
/archives/netdev/2004-01/msg00479.html (13,321 bytes)

10. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: ler" <davem@xxxxxxxxxx>
Date: Thu, 22 Jan 2004 14:50:15 -0800
Isn't memory barrier used to stop re-ordering of instructions and needs to be present in both reader as well as writer to have synchronization since mb is for the CPU on which it is executing ? In t
/archives/netdev/2004-01/msg00481.html (12,260 bytes)

11. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: @xxxxxxxxxx>
Date: Thu, 22 Jan 2004 16:35:04 -0800 (PST)
You are correct. Good thing I delayed this for a release, now we can work on making sure we get this right. :-)
/archives/netdev/2004-01/msg00486.html (10,383 bytes)

12. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: n <shmulik.hen@xxxxxxxxx>
Date: Thu, 22 Jan 2004 17:08:04 -0800
Do you really care about this situation? It only happens as a race within one instruction in 4 billion. It will slow everytime if we do this way. Thanks Shirley Ma IBM Linux Technology Center 15300 S
/archives/netdev/2004-01/msg00489.html (10,081 bytes)

13. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: muel Hen <shmulik.hen@xxxxxxxxx>
Date: Thu, 22 Jan 2004 17:43:19 -0800 (PST)
correctness > performance If MRTG hits this case and my net usage graphs have weird spikes in them as a result, can I assign the bugzilla entry to you? :-)
/archives/netdev/2004-01/msg00490.html (10,182 bytes)

14. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: r" <davem@xxxxxxxxxx>
Date: Thu, 22 Jan 2004 18:45:18 -0800
Hi dave, If so, do you think the solution that I proposed earlier would work ? No doubt it is quite ugly to behold :-) The one issue with it is one extra cache loading in 99.999999999% of cases (2 in
/archives/netdev/2004-01/msg00497.html (11,113 bytes)

15. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: <dlstevens@xxxxxxxxxx>
Date: Thu, 22 Jan 2004 18:57:16 -0800
I agree with this statement, if every bug is explained as a "very tiny race" leads to one large defective product :-) and performance also need not be hit much if writers are not penalized as I had
/archives/netdev/2004-01/msg00498.html (9,496 bytes)

16. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: em@xxxxxxxxxx>
Date: Fri, 23 Jan 2004 10:06:00 -0800
OK, I am fixing the reader and will resubmit it when next release is available. Thanks Shirley Ma IBM Linux Technology Center 15300 SW Koll Parkway Beaverton, OR 97006-6063 Phone: (503) 578-7638 FAX
/archives/netdev/2004-01/msg00505.html (9,364 bytes)

17. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: xxxxxxxxxx>
Date: Wed, 28 Jan 2004 11:09:45 -0800
I don't understand how your scheme can work. We're trying to detect if the upper 32-bit half of the 64-bit value belongs with the lower-half. We can overflow the lower-half TWICE in the res1=...res2=
/archives/netdev/2004-01/msg00658.html (10,339 bytes)

18. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: xxxxxxxx>
Date: Wed, 28 Jan 2004 11:19:36 -0800
Hi Dave, The snippet assumed that the number will not overflow 4G times twice within two reads, which I thought was quite a reasonable assumption. I think a fast and clean solution is using Seq locks
/archives/netdev/2004-01/msg00659.html (11,972 bytes)

19. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: xxxxx>
Date: Wed, 28 Jan 2004 11:33:36 -0800
[ ... idea to use seq locks ] Well, I thought the goal was to move the expensive part of doing this out of the writers, which we assume will exceed readers. Seq locks favor readers, and assume that t
/archives/netdev/2004-01/msg00660.html (9,546 bytes)

20. Re: [PATCH]snmp6 64-bit counter support in proc.c (score: 1)
Author: S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 28 Jan 2004 12:09:15 -0800
Yes. Dave, could we create a new interface to avoid the spin_lock? Example 1: modify write_seqlock(set_lock *s) to write_seqlock(seq_lock *s, int lock), it will modify all calling routines. Example
/archives/netdev/2004-01/msg00666.html (9,271 bytes)


This search system is powered by Namazu