On Sun, Jul 11, 2010 at 11:27 AM, Robert N. M. Watson
wrote:
> [..] a duplicated carry(for example) [..] is not really acceptable.
I see. It would be nice to model such extreme cases somehow, so we
could test them against different solutions.
> What sort of measurement did you do to show the s
On 07/11/10 18:24, Kostik Belousov wrote:
> On Fri, Jul 09, 2010 at 01:03:14PM +1000, Lawrence Stewart wrote:
>> On 06/18/10 11:57, Lawrence Stewart wrote:
>>> On 06/17/10 17:13, Kostik Belousov wrote:
On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote:
> On 06/14/10 20:43, K
On 11 Jul 2010, at 04:18, Gabor PALI wrote:
> On Sat, Jul 10, 2010 at 5:24 PM, Robert N. M. Watson
> wrote:
>> If we can do it in one atomic in the common case, and two atomics in an edge
>> case, that sounds fine. I think any use of locking(9) would be sufficiently
>> costly as to not be wort
On Fri, Jul 09, 2010 at 01:03:14PM +1000, Lawrence Stewart wrote:
> On 06/18/10 11:57, Lawrence Stewart wrote:
> > On 06/17/10 17:13, Kostik Belousov wrote:
> >> On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote:
> >>> On 06/14/10 20:43, Kostik Belousov wrote:
> > [snip]
> Or, y
On Sat, Jul 10, 2010 at 5:24 PM, Robert N. M. Watson
wrote:
> If we can do it in one atomic in the common case, and two atomics in an edge
> case, that sounds fine. I think any use of locking(9) would be sufficiently
> costly as to not be worth the improvements in consistency, given the
> frequ
On 9 Jul 2010, at 19:58, Gabor PALI wrote:
>> I assume there are reasonable alternatives that work around the
>> potential race with a small probability of a missed or extra update,
>> or similar, which would be fine.
>
> In a few words: As far as I know, 64-bit atomic counters could be
> imple
On 07/09/10 20:50, Robert Watson wrote:
> I think I have an e-mail in my in queue from you suggesting an
> alternative approach that I haven't yet gotten to due to utter
> saturation here.
That is why I CC'ed svn-src-head@ :) (But I do not see any sign whether
my last email reached it -- I am not
On 06/18/10 14:08, Robert Watson wrote:
> 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
On Fri, 9 Jul 2010, Gabor PALI wrote:
On 06/18/10 14:08, Robert Watson wrote:
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
On 06/18/10 11:57, Lawrence Stewart wrote:
> On 06/17/10 17:13, Kostik Belousov wrote:
>> On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote:
>>> On 06/14/10 20:43, Kostik Belousov wrote:
> [snip]
Or, you could ditch the sum at all, indeed using ({}) and returning the
result
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
s
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
On 06/17/10 17:13, Kostik Belousov wrote:
On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote:
On 06/14/10 20:43, Kostik Belousov wrote:
[snip]
Or, you could ditch the sum at all, indeed using ({}) and returning the
result. __typeof is your friend to select proper type of accumula
On Thu, 17 Jun 2010, Kostik Belousov wrote:
On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote:
I've tested the above and it works. I also prefer the idea of having
DPCPU_SUM return the sum so that you can do "var = DPCPU_SUM(...)". My
only concern with this method is that the cal
On Thu, Jun 17, 2010 at 12:38:08PM +1000, Lawrence Stewart wrote:
> On 06/14/10 20:43, Kostik Belousov wrote:
> >On Mon, Jun 14, 2010 at 08:34:15PM +1000, Lawrence Stewart wrote:
> >>On 06/14/10 18:52, Kostik Belousov wrote:
> >>>On Mon, Jun 14, 2010 at 11:52:49AM +1000, Lawrence Stewart wrote:
> >
On 06/14/10 20:43, Kostik Belousov wrote:
On Mon, Jun 14, 2010 at 08:34:15PM +1000, Lawrence Stewart wrote:
On 06/14/10 18:52, Kostik Belousov wrote:
On Mon, Jun 14, 2010 at 11:52:49AM +1000, Lawrence Stewart wrote:
On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
On Sun, Jun 13, 2010 at 02:39:5
On Mon, 14 Jun 2010, John Baldwin wrote:
On Monday 14 June 2010 9:50:10 am m...@freebsd.org wrote:
[bde wrote]
BTW, one reason I liked BSD code more than gnu code is that it didn't
use so many macros. Macros should only exist when they are not just
syntactic sugar, like DPCPU_SUM() and unlike
On Monday 14 June 2010 9:50:10 am m...@freebsd.org wrote:
> > BTW, one reason I liked BSD code more than gnu code is that it didn't
> > use so many macros. Macros should only exist when they are not just
> > syntactic sugar, like DPCPU_SUM() and unlike CPU_FOREACH().
>
> As a style question, I do
> BTW, one reason I liked BSD code more than gnu code is that it didn't
> use so many macros. Macros should only exist when they are not just
> syntactic sugar, like DPCPU_SUM() and unlike CPU_FOREACH().
As a style question, I do understand (generally) why too many macros
make the code confusing.
On Sunday 13 June 2010 9:41:38 am Lawrence Stewart wrote:
> On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
> > On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
> >> Author: lstewart
> >> Date: Sun Jun 13 02:39:55 2010
> >> New Revision: 209119
> >> URL: http://svn.freebsd.org/change
On Sun, 13 Jun 2010, Lawrence Stewart wrote:
On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
Log:
Add a utility macro to simplify calculating an aggregate sum from a
DPCPU
counter variable.
Sponsored by:FreeBSD
On Sun, 13 Jun 2010, Gabor Kovesdan wrote:
+/*
+ * Utility macros.
+ */
+#define DPCPU_SUM(n, var, sum)
\
+do {
\
+ (sum) = 0; \
+ u_int i;\
+ CPU_FOREACH(i)
On Mon, Jun 14, 2010 at 08:34:15PM +1000, Lawrence Stewart wrote:
> On 06/14/10 18:52, Kostik Belousov wrote:
> >On Mon, Jun 14, 2010 at 11:52:49AM +1000, Lawrence Stewart wrote:
> >>On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
> >>>On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
On 06/14/10 18:52, Kostik Belousov wrote:
On Mon, Jun 14, 2010 at 11:52:49AM +1000, Lawrence Stewart wrote:
On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
[snip]
Modified: head/sys/sys/pcpu.h
===
On Mon, Jun 14, 2010 at 11:52:49AM +1000, Lawrence Stewart wrote:
> On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
> >On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
> [snip]
> >>
> >>Modified: head/sys/sys/pcpu.h
> >>
On Mon, Jun 14, 2010 at 11:52:49AM +1000, Lawrence Stewart wrote:
> Given that the DPCPU variable name space is flat and variable names have
> to be unique, perhaps something like the following would address the
> concerns raised?
>
> #define DPCPU_SUM(n, var, sum)
On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
[snip]
Modified: head/sys/sys/pcpu.h
==
--- head/sys/sys/pcpu.h Sun Jun 13 01:27:29 2010(r209118)
On Sun, Jun 13, 2010 at 01:59:11PM +, m...@freebsd.org wrote:
>
> (Relevant but almost a thread hijack):
>
> At Isilon we've run into a lot of problems with variable declarations
> in macros, especially with -Wshadow turned on. We ended up
> backporting __COUNTER__ from later versions of gcc
On Sun, Jun 13, 2010 at 01:59:11PM +, m...@freebsd.org wrote:
> On Sun, Jun 13, 2010 at 10:10 AM, Pawel Jakub Dawidek
> wrote:
> > On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
> >> Author: lstewart
> >> Date: Sun Jun 13 02:39:55 2010
> >> New Revision: 209119
> >> URL: ht
On Sun, Jun 13, 2010 at 10:10 AM, Pawel Jakub Dawidek wrote:
> On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
>> Author: lstewart
>> Date: Sun Jun 13 02:39:55 2010
>> New Revision: 209119
>> URL: http://svn.freebsd.org/changeset/base/209119
>>
>> Log:
>> Add a utility macro to
On 06/13/10 20:10, Pawel Jakub Dawidek wrote:
On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
Author: lstewart
Date: Sun Jun 13 02:39:55 2010
New Revision: 209119
URL: http://svn.freebsd.org/changeset/base/209119
Log:
Add a utility macro to simplify calculating an aggregate
On 06/13/10 20:20, Gabor Kovesdan wrote:
+/*
+ * Utility macros.
+ */
+#define DPCPU_SUM(n, var, sum) \
+do { \
+ (sum) = 0; \
+ u_int i; \
+ CPU_FOREACH(i) \
+ (sum) += (DPCPU_ID_PTR(i, n))->var; \
+} while (0)
I'd suggest first swapping variable declaration and '(sum) = 0;'.
Also using 'i'
+/*
+ * Utility macros.
+ */
+#define DPCPU_SUM(n, var, sum) \
+do { \
+ (sum) = 0; \
+ u_int i;
On Sun, Jun 13, 2010 at 02:39:55AM +, Lawrence Stewart wrote:
> Author: lstewart
> Date: Sun Jun 13 02:39:55 2010
> New Revision: 209119
> URL: http://svn.freebsd.org/changeset/base/209119
>
> Log:
> Add a utility macro to simplify calculating an aggregate sum from a DPCPU
> counter variab
Author: lstewart
Date: Sun Jun 13 02:39:55 2010
New Revision: 209119
URL: http://svn.freebsd.org/changeset/base/209119
Log:
Add a utility macro to simplify calculating an aggregate sum from a DPCPU
counter variable.
Sponsored by: FreeBSD Foundation
Reviewed by: jhb, rpaulo, rwatson (pr
35 matches
Mail list logo
