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