Date: Fri, 28 Dec 2001 23:28:18 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Michal Mertl <mime@traveller.cz> Cc: arch@FreeBSD.ORG, John Hanley <jh_@yahoo.com>, Alfred Perlstein <bright@mu.org>, Matthew Dillon <dillon@apollo.backplane.com>, Mike Smith <msmith@FreeBSD.ORG> Subject: Re: 64 bit counters Message-ID: <XFMail.011228232818.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.41.0112272240370.96716-100000@prg.traveller.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27-Dec-01 Michal Mertl wrote: > On Thu, 27 Dec 2001, Mike Smith wrote: >> > :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. >> > >> > You are absolutely right. The carry will only be set on the addl >> > which overflows the 32 bit counter and will not be set on any of >> > the other addl's that might be occuring just before, inbetween the >> > two instructions, or just after. So only one of those will cause the >> > msb to increment. >> > >> > For UP the addl instruction is atomic. For SMP we still have to lock >> > the >> > bus cycle. Something like this: >> > >> > lock; addl %eax,(u_int64_t) >> > lock; adcl $0,4(u_int64_t) >> >> This is all well and good, but not portable. > > Aren't all other architectures we support 64 bit? On i386 even present > form (32 bit addition) isn't atomic (no lock involved). On i386 for 64 > bits the compiler generates the code above (without locks) and on 64 bit > platforms I expect it would generate something at least similarly atomic > like 32 bit addition on i386 we use today (both stable and current). On > i586 we can have 64 bit atomic operations with cmpxchg8b. On Aplha I think > the long is 64 bit so counters are already 64 bit. > > Anyway the code probably should be rewritten to use mutexes or atomic > operations or whatever. I'll look at some current sources and maybe I'll > be able to understand what are all these locks, mutexes, msleep and so on. > > In the time being I'll keep my naive patch to add the functionality to > stable (it happens to work (probably only in 99.99999% of time and bit > less on SMP)). You can use cmpxchg8b on SMP systems (it's available on all machines that support SMP I think) and use non-SMP versions otherwise where needed. You would just implement the atomic_foo_64 versions this way. You would need to use cmpxchg8b instead of addl/adcl for the acq and rel variants for SMP. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.011228232818.jhb>