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
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
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
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 *
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.
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
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
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
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
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
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
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? :-)
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
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
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
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=
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
[ ... 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
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