Date: Tue, 15 Jan 2002 12:37:02 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Michal Mertl <mime@traveller.cz> Cc: Bosko Milekic <bmilekic@technokratis.com>, "James E. Housley" <jeh@FreeBSD.ORG>, Thomas Hurst <tom.hurst@clara.net>, arch@FreeBSD.ORG Subject: Re: 64 bit counters again Message-ID: <3C4492EE.5A60AD0B@mindspring.com> References: <Pine.BSF.4.41.0201141848330.82342-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Michal Mertl wrote: > I wrote it so it's just matter of one #define change to have all counters > switch to 32 or 64 bit. It also would be possible to have something like > atomic funtctions - different counter functions for various counter sizes, > maybe even something like "use counter at least 32 bits wide - If we need > atomicity on <586 we can't simply implement these ops" - I agree that some > counters would have sufficient precision and scale in 32 bit. If it is #if'ed (e.g. "#if (sizeof(long)>=8) || FORCE_64_BIT_CONUTERS"), then I have no problem with the code going in, so long as it is off by default on 32 bit machines. > I kind of measured the speed of just different addition implementation > (DUAL pIII cumine, ServerWorks and 440BX dual boards with SMP kernel) - [ ... ] > It seems you and others were right. SMP atomic implementations are a bit > expensive. But even the worst case 50 clocks for locked cmpxchg8b isn't > that bad but IMMV. Uh, that's a factor of 16 in the cases that I think most of us will care about, so I think MMDV. [ ... ] > 32 bit simple (compiler generates read-modify-write - wrong but used > throughout kernel!!!, only when counter variable is declared volatile > compiler generates addl change,(mem)): 3.00 Ugh. This looks like it needs to be fixed! Amazing what you find when you gice something a hard look... > --- > > I totally disagree with Terry that 64 bit counter is only slightly more > difficult to overflow then 32 bit. We will never (in near future - several > years) have terabit interfaces nor wirespeed 10Gbit (and 10Gbit fullduplex > would overflow in 500 years). If you don't like 64 bit, your fix (to count > in KB) only adds 10 bits of range, switch to 64 bit adds 32 bit. I > understand that global counter could be made 64 bit a the counter you're > actually counting on 32 bit so you would add 42 bits. That won't overflow > for sure :-). FWIW, HP is selling 10Gbit parts now; you can buy the cards from them online today, if you wanted to. It is very likely that we will see IA64 based networking hardware to support multiple ports on these things. 10 ports is 100Gbit. That puts us within one order of magnitude of terabit. Are you sure you want to challenge Moore's law like that? 8-). > I deeply apologise that the patch I posted was badly broken. I revamped > the code quite a lot before doing the diff and it resulted in lots of > cut-n-paste and similar errors :-(. Kernel&world build went without > problems but the code was wrong (in atomic.h and syscntr.h). New patch > will be available soon. If it conditionalizes the code so that the default disables 64 bit on 32 bit machines, I have no problem with it. If people really want 64 bit features, there's an easy fix for the problem: buy a 64 bit machine. Allowing people to use 64 bit features at 1500% inflation in cost is OK, if it is not on by default, and has to be willfully turned on (I would prefer that it has to be done by reading a warning first). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C4492EE.5A60AD0B>