[Openmcl-devel] Quick HW question...

[Jon Anthony]

Many Thanks for the info.

On Mon, 2010-11-15 at 14:32 -0700, Gary Byers wrote:
> Someone asked about the i7, and I remember professing ignorance (several
> paragraphs of it.)
> 
> The Mac Pro (at least some models) use/have used Intel XEON processors
> which in turn use HTT; it's reasonable to assume that the OSX scheduler's
> been HTT-aware for some time.  (I don't know if it's true, but it's a
> reasonable assumption.)
> 
> CCL uses spinlocks on most platforms; acquiring a spinlock involves a
> loop like:
> 
> (block got-lock
>    (loop
>      (dotimes (i *spin-lock-tries*)
>        (if (%store-conditional something somewhere)
>          (return-from got-lock t)))
>      (give-up-timeslice)))
> 
> where *spin-lock-tries* is 1 on a uniprocessor system and maybe a few
> thousand on a multiprocessor system.  On a system that uses
> hyperthreading, that sort of loop interferes with the hardware's 
> ability to schedule another hardware thread, and it's necessary to
> use a special "pause" instruction (a kind of NOP) in the loop to
> advise the hardware that the current thread wasn't really making
> progress.

I've seen something like that idiom in some LAP function(s), with the
'pause' instruction included.  But there was an additional outer loop of
"timeout tries", with yields for each, where a yield is a punt to the
OS.  This was on Linux x8632.


> While profiling a customer's application a few years ago, we found
> that - when run on XEONs - a lot of time was reported as being spent
> looping around waiting for spinlocks.  I said "D'oh!" and added a
> "pause" instruction on the execution path, but that didn't make things
> better; on Linux, we replaced the use of spinlocks with a slightly
> more expensive mechanism, and (paradoxically) things improved, at least
> on the XEONs.
> 
> That never made sense to me, and I always suspected that something was
> just wrong in the implementation (the "pause" instruction happened
> out-of-line) or that we were seeing profiling artifacts.  At the time,
> there wasn't time to explore this issue more fully, but those suspicions
> have lingered.
> 
> CCL generally does a lot less locking (of hash-tables, streams, ...) 
> than it did a few years ago.  We still use spinlocks (some) on
> non-Linux platforms, so if there was a bad interaction between spinlock
> loops and hyperthreading it's likely still there but may not show up
> as often.

OK, noted (and those lockless entities are definitely nice!)


> Other than that issue, I'm not aware of any way in which HTT is directly
> visible to non-OS code.

OK, thanks!


/Jon

> 
> 
> 
> On Mon, 15 Nov 2010, Jon Anthony wrote:
> 
> > Hi,
> >
> > I know the Wiki page for SysReq states no known issues with X86_64, but
> > I seem to recall something passing through here about some "issue" with
> > Intel Core i7 on Mac, or maybe generally, or am I just plain
> > misremembering?  On a related note, does MacOS understand HTT (does it
> > know the diff between physical and logical cores)?  Thanks for any info!
> >
> > /Jon
> >
> >
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://clozure.com/mailman/listinfo/openmcl-devel
> >
> >