FC5T2 and Development issues, observations, and questions

Dave Jones davej at redhat.com
Tue Jan 17 18:41:57 UTC 2006


On Tue, Jan 17, 2006 at 10:29:29AM -0800, Nathan Grennan wrote:

 >  I disagree, I suspect there are still a lot more non-dual/ht systems 
 > out there. I just upgraded to dual core A64. They come at quite a 
 > premium. It also isn't like a ton of S754 systems and S939 single core 
 > systems haven't been sold. I will give you that there are a fair number 
 > of HT systems out there, but again they are only on the higher end 
 > versions of the processor. In addition may people disable HT worse 
 > performance under certain workloads.

The spinlock operations are almost free on AMD on UP.  They did some real
magic in their cores to make locked operations really fast compared to Netburst.
Intel however haven't shipped *any* UP x86-64's. Even the first ones
they shipped were HT capable.

 > How much of a performance loss is the extra overhead of the 
 > spinlocks? I would suspect that some people would recompile the kernel 
 > for UP if the overhead is high enough.

There's a *tiny* performance hit on UP (mostly observable on Intel
where its irrelevant -- and as I said in an earlier mail, there's
working going on to NOP the LOCK prefixes when a single CPU is found anyway).
It's not like we've lost some huge percentage of overall performance here.

Also, the UP kernels have CONFIG_DEBUG_SPINLOCKS enabled anyway, to
increase coverage testing, to try and catch bugs before they happen.
(A number of the IDE locking bugs Alan fixed circa 2.6.10 came from
 reports on UP machines).

 >  I can understand how it makes life easier for the developers, but from 
 > past experience when corners are cut like this a corner case always 
 > seems to come up. One that comes to mind is if a driver is known to not 
 > play well with SMP

Then the driver needs fixing. But as this is just rhetoric, it's irrelevant.
Switching to a different kernel when a bug hits you isn't the answer.

		Dave




More information about the fedora-test-list mailing list