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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
