Date: Sat, 19 Jun 2010 13:29:51 +1000 From: Lawrence Stewart <lstewart@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Matthew Fleming <mdf@FreeBSD.org>, src-committers@FreeBSD.org, Pawel Jakub Dawidek <pjd@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org, brde@optusnet.com.au, Kostik Belousov <kostikbel@gmail.com> Subject: Re: svn commit: r209119 - head/sys/sys Message-ID: <4C1C39AF.5010906@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1006181307360.90129@fledge.watson.org> References: <201006130239.o5D2du3m086332@svn.freebsd.org> <20100613101025.GD1320@garage.freebsd.pl> <4C158B71.205@freebsd.org> <20100614085205.GD13238@deviant.kiev.zoral.com.ua> <4C1605A7.2000202@freebsd.org> <20100614104349.GF13238@deviant.kiev.zoral.com.ua> <4C198A90.3060905@freebsd.org> <20100617071300.GX13238@deviant.kiev.zoral.com.ua> <4C1AD292.5070508@freebsd.org> <alpine.BSF.2.00.1006181307360.90129@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/18/10 22:08, Robert Watson wrote: > > On Fri, 18 Jun 2010, Lawrence Stewart wrote: > >> True but I figured on large SMP systems where the potential to process >> more is likely, 32bit counters per cpu may be enough to avoid overflow >> but the aggregate number of events may exceed a 32bit variable. I >> suspect you're right though and that if there's a likely chance the >> aggregate could overflow, then the DPCPU var should simply be made >> 64bit to also remove any possibility of individual PCPU counters >> overflowing. >> >> I'll commit the above version of the macro this evening (GMT+10) >> unless I hear any objections. Thanks to all of you for your input. I've just committed the updated macro to at least get the new calling syntax settled in. > The only reservation I have, really, is that 64-bit writes are > non-atomic on i386 and other 32-bit architectures (or, at least, I think > they are). This means DPCPU_SUM may encounter non-atomicity rather than > just staleness in the values it reads as it iterates. That said, we > should probably use 64-bit anyway, because 32-bit counters are gauche. :-) hrm that's messy and somewhat useless. Are there some tricks we can add to force a flush of any outstanding writes to the DPCPU var on the cpu we're reading from to ensure the counter is at least stable at the time we read? This stuff is way beyond my realm of knowledge so I defer to the greater wisdom of the masses on this. Cheers, Lawrence
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C1C39AF.5010906>