svn commit: r202889 - head/sys/kern

[John Baldwin]

On Tuesday 26 January 2010 3:58:45 am Attilio Rao wrote:
> Finally, I really don't think the BLOCK_SPIN() performance improvement
> you suggest should really make a difference (assuming how rarely it
> should happen) because, please note, that the cmpxchg is necessary as
> we need to enforce a memory barrier when doing the check in anyway (so
> the first case should be however an atomic_cmpset_X_Y()).

Note that Intel specifically mentions in the app note that introduced 'pause' 
that one should not sit in a spin loop that bangs on cmpxchg due to the extra 
cache contention it causes.  Also, I did not say to remove the cmpxchg, but to 
only do it if a 'cmp' indicates it should work.  We already do this now for 
mtx_lock_spin() in C with something like this:

	while (!atomic_cmpset_acq_ptr(...)) {
		while (m->mtx_lock != MTX_UNOWNED) {
			cpu_spinwait();
		}
	}

The idea is to do "cheap" compares that do not require an exclusive hold on 
the cache line until you have a reason to think that the cmpxchg will "work".

> Last thinking: it is not a very good idea cpu_switch() is made
> conditional in regard of schedulers, but there is not an easy way to
> do that as long as the safe points for releasing blocked_lock happens
> within cpu_switch(). I think that is one of the reasons why some
> people (maybe you or Jeff) pushed for having cpu_switch() made in C.

Would the complicated version of BLOCK_SWITCH() work ok for the sched_4bsd and 
ULE/UP case and just devolve into normally not spinning?

-- 
John Baldwin