Date: Wed, 26 Dec 2001 23:45:36 +0100 (CET) From: Michal Mertl <mime@traveller.cz> To: Alfred Perlstein <bright@mu.org> Cc: Mike Smith <msmith@freebsd.org>, John Hanley <jh_@yahoo.com>, <arch@freebsd.org> Subject: Re: 64 bit counters Message-ID: <Pine.BSF.4.41.0112262252210.33404-100000@prg.traveller.cz> In-Reply-To: <20011226135902.O91594@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Dec 2001, Alfred Perlstein wrote: > * Mike Smith <msmith@freebsd.org> [011226 13:40] wrote: > > > On Tue, 25 Dec 2001, John Hanley wrote: > > > > > > Well I didn't think of that but I believe it shouldn't be that much a > > > problem. At most the counter could become wrong :-). > > > > This would be completely unacceptable. > > Agreed. > > A lot of people think that a small window where data is inconsistant > and exposed to other subsystems is acceptable. This is far from > the truth, if a decision is made based on an incorrect counter or > that incorrect counter value is then used in some critical function > the entire system will obviously misbehave. > Ok. It seems to me a bit like that sio problem. There is a problem lot of people experience (I had it too on 4.3 but on 4.5PRE it's gone). There is known quick and working workaround (Matt's) - yet it is unacceptable. One reason to not use the workaround was (not quoting MAINTAINER precisely): "I keep this partly as a check if the interrupt latency didn't get even worse" which seems quite strange to me. So we have for years problem for which exists generally usable workaround. We have counters which overflow pretty often (one guy wrote they overflow for him every 1-2 minutes) - they're almost useless. They aren't updated with atomic_?? (are they then guaranteed to contain the right value?) but there maybe isn't the need since they're 32bit. I thought about possibility of the counter to become wrong a lot and think the counter (at least the counters I was thinking about implementing) can never become wrong. It can probably be wrong by 0x100000000 for the very short moment and I don't know how to reliably check if at the time of reading the value isn't wrong. Maybe doing two reads. Why do I think it never becomes wrong? Generally I'm adding rather small value (<1e6 or so) to 64 bit counter. When one addition overflows less significant 32 bits, several next additions don't overflow. u_int64_t+=u_long is: addl %eax,(u_int64_t) ; this is atomic, right? adcl $0,4(u_int64_t) If interrupt occurs in between these two instructions, then the less significant halt is right and more significant will be fixed after the execution returns to second instruction. Even if the interrupt modified the value, we can expect (read - be sure) it didn't modify the more significant half. So I see here two problems: how to read the value and how to assure we won't use the same principle on counters which grow much faster. If you thing this is really unacceptable, I don't blame you. It really isn't perfect (nothing else is either). If I was looking for quick fix I woudln't look any further (I can't see any serious use for the counters - for me they're just providing an insight on the system and then there is more important behaviour in time than exact value). On arch list we probably talk about "the real solutions" which this approach doesn't provide. I'm just afraid I won't be able to help with more "mature" approach. Locking etc. is beyond my abilities. If someone tells me what/how to code - Mike Smith's approach or whatever - I can try to work on that too but I can't promiss anything then. BTW Mike Smith's approach isn't that much better - there can be overflow of the less significant 32 bit (which is unlikely but more likely than in my naive approach). Only there would be guaranteed contents of 64 bit counter - which is probably the improtant part. Still willing to work on making FreeBSD even better :-). -- Michal Mertl mime@traveller.cz 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?Pine.BSF.4.41.0112262252210.33404-100000>