FC5T2 and Development issues, observations, and questions

[Nathan Grennan]

Dave Jones wrote:
> On Tue, Jan 17, 2006 at 08:59:57AM -0800, Nathan Grennan wrote:
>
>  > 2. What is up with x86_64 kernels always being SMP enabled? I noticed a 
>  > comment in the release notes, but no reason given as to why. I would 
>  > think this could be problematic for debugging unless there is some boot 
>  > option that makes the kernel act 100% like it would with a UP kernel.
>
> It's been covered on the lists a few times.  In short, the number of
> dual-core/hyperthreaded/smp x86-64s in the wild far outweigh the
> uniprocessor variants (soon, even laptops will be moving to dual-core/HT),
> and the overhead of running spinlocks on UP is negligable
> (and there's work ongoing to make it disappear completely).
>   
  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.

   I do think that in the long run SMP will dominate, but your analysis 
seems pre-mature. I suspect we are at least a year if not two before SMP 
dominates.

   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.
> Less kernel images overall is a good thing for a number of reasons.
> less cd space, less mirror bandwidth, faster build times, being some of
> the 'off the top of my head' answers, but there's also value in having
> every system going through the same codepath from a debugging standpoint.
>
>   
  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, and now you just forced a person with a non-SMP cpu 
to deal with a bug he wouldn't normally have to deal with. His only 
recourse will likely be to not use x86_64 and revert back to i386 as 
some many people already do to avoid multi-lib related issues.