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.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list