Date: Mon, 14 Jan 2002 18:47:14 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "James E. Housley" <jeh@FreeBSD.org> Cc: David Greenman <dg@root.com>, Bosko Milekic <bmilekic@technokratis.com>, Thomas Hurst <tom.hurst@clara.net>, arch@FreeBSD.org Subject: Re: 64 bit counters again Message-ID: <3C439832.C52B4379@mindspring.com> References: <Pine.BSF.4.41.0201132057560.62182-100000@prg.traveller.cz> <3C41F3FD.4ECC8CD@mindspring.com> <20020113231459.GA30349@voi.aagh.net> <3C42390A.F9E9F533@mindspring.com> <3C42E899.CB21BD0A@FreeBSD.org> <20020114105859.A24635@technokratis.com> <3C4305E5.65BB32A6@FreeBSD.org> <20020114114911.A24990@technokratis.com> <20020114094738.A8955@nexus.root.com> <3C4334A1.6601C5ED@mindspring.com> <3C4338EA.1D698EF1@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"James E. Housley" wrote: > > It's just as obvious that, since the counting occurs at > > interrupt, making atomicity guarantees in the face of hardware > > interrupts potentially occurring between component instructions > > is going to be a computationally expensive proposition. > > What a minute. If we are in the interrupt routine for this piece of > hardware and interrupts. Why can't we do the addition during this > initial poriton while the interrupts are blocked. No one else should be > incrementing this counter since we are presently servicing it. I do > understand that in a SMP system there could be a problem with reading > the data correctly, so this might not work. It's a good idea, but it won't work with the direction FreeBSD is headed with regards to processing interrupts in "ithreads". The problem is that the actual increment will be in the "top end" interrupt thread, not in the "bottom end" ISR handler. > That sounds reasonable. 1024 might be a problem becuase of smaller ACK > or setup packets, but the concept is reasonable. I would like to know > the amount of data transmitted and received because that is what we are > billed on. And at that datarate, to the bit accuracy is crazy. But the > results should be close enough to reality to be able to trust it with a > small fudge fact for saftey. See the pseudo-code in my previous posting. Having a lower precision on the reported value is not the same thing as losing accuracy. The smaller ACK and setup packets would be counted at the byte level by the modular counter, without damaging the accuracy of the count. In fact, if you were willing to take it in two pieces at splimp, you could report accuract to the byte in a 64 bit value, if you were hell-bent on doing that, with the only real impact being at the time of the report, rather than at the time of the count (which is what I'm trying to avoid here). -- 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?3C439832.C52B4379>