Date: Mon, 24 Jul 2006 10:40:27 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-current@FreeBSD.ORG Subject: Re: vmstat's entries type Message-ID: <200607240840.k6O8eRJn037554@lurza.secnetix.de> In-Reply-To: <44C40E66.8080805@wm-access.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Sten Daniel Sørsdal <lists@wm-access.no> wrote: > sthaug@nethelp.no wrote: > > > > > > One approach that we could use for 64-bit counters would be to just > > > > use 32-bits one, and poll them for overflow and bump an overflow > > > > count. This assumes that the 32-bit counters overflow much less often > > > > than the polling interval, and easily triples the amount of storage > > > > for each of them... It is ugly :-( > > > > > > > What's wrong with the add+adc (asm) approach found on any i386? > > > > Presumably the fact that add + adc isn't an atomic operation. So if > > you want to guarantee 64 bit consistency, you need locking or similar. > > Would it not be necessary to do this locking anyway? > I don't see how polling for overflow would help this consistency. When using the polling solution, the overhead of checking for atomicity is moved to the "client" side, so no locking is necessary. The idea is that most counters are updated much more often than they're read, so the updating code should be as efficient as possible, at the cost of more overhead in the reading code. For example, the code reading the sysctl has to perform the following actions (pseudo code): 1. OV1 = read overflow counter 2. OLD = read old counter value 3. NEW = read new counter value 4. OV2 = read overflow counter 5. if OV2 != OV1: go back to 1. 6. if OLD > NEW: OV1++ 7. return OV1 * 2^32 + NEW I think that should cover all possible race conditions. The code updating the overflow counter at certain polling intervals would have to do something similar, of course. The main advantage of that approach is the fact that the counter updating code is a simple 32bit "add". There's no locking or anything required, i.e. it's most efficient, which is important if the counter is updated very often, like vm.stats.sys.v_swtch or vm.stats.sys.v_syscall or vm.stats.sys.v_intr. The disadvantage is that polling the counters for overflows is somewhat ugly, in terms of design. However, personally I think that it's an acceptable solution, given the fact that it is only required for 32bit "legacy" hardware. 64bit machines will be more and more common and become the "standard", and they don't need such work-arounds for 64bit counters. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607240840.k6O8eRJn037554>