Re: vmstat's entries type

On Friday 28 July 2006 17:01, Peter Jeremy wrote:
> On Fri, 2006-Jul-28 14:47:01 +0100, Brian Candler wrote:
> >On Fri, Jul 28, 2006 at 09:28:36AM -0400, John Baldwin wrote:
> >> 	lock incl counter
> >> 	jnc 1f
> >> 	lock incl counter+4
> >> 1:
> 
> This approach still requires the reader to loop with something like
> 	do {
> 		a.lo = counter.lo;
> 		a.hi = counter.hi;
> 		b.lo = counter.lo;
> 		b.hi = counter.hi;
> 	} while (a.hi != b.hi || a.lo > b.lo);
> to ensure that the reader doesn't read the middle of an update.

Yes, but the idea here is that these stats are written to far more often than 
read, so it's ok to pessimize the read case.

> lock prefixes are always going to be extremely expensive on a MP
> system because they require physical bus cycles.  RISC architectures
> usually only have TAS lock primitives (because "inc mem" doesn't
> exist) and so require a spinlock to perform an atomic update.

Nah, you can do it directly using different primitives w/o a full spin lock.  
If you had a 32-bit RISC arch that supported linked-load conditional-store 
like Alpha/MIPS you could do something like:

1:
	ldl_l	t0, (a0)
	addi	t0, 1
	mov	t2, t0  # or add t2, t0, zero
	stl_c	t0, (a0)
	beq	t0, 1b
	bne	t2, 2f	# skip next if we didn't wrap
2:	
	ldl_l	t0, 4(a0)
	addi	t0, 1
	stl_c	t0, (a0)
	beq	t0, 2b

That doesn't require a full-blow spinlock which disables interrupts, etc.

> In a MP configuration where it doesn't particularly matter if a
> particular update gets counted this time or next time, I think the
> cheapest option is to have per-CPU 32-bit counters (so no locks are
> needed to update the counters) with a polling function to accumulate
> all the individual counters into a 64-bit total.  This pushes the cost
> from the update (very frequent) into the read (which is relatively
> infrequent), for a lower overall cost.
> 
> This turns the update into something like:
> 	PCPU_SET(counter, PCPU_GET(counter)+1);
> or
> 	incl	%fs:counter
> (no locks or atomic operations)

Note that if you go with per-cpu counters then you don't need 'lock' prefixes 
for the 'inc; jnc 1f; inc; 1:' case either.

-- 
John Baldwin