On Mon, Aug 14, 2006 at 04:33:09PM -0000, Ben Collins wrote: > On Mon, 2006-08-14 at 16:09 +0000, Matt Zimmerman wrote: > > We should standardize on a kernel which supports multiprocessor/multicore > > systems, as they are becoming very common in desktops. > > I'm not saying that -686 is only meant for SMP, I'm saying that > generally, it's not going to give much benefit except on those systems. > Certain situations, even on UP call for the -686 kernel (e.g. running > 32-bit on a xeon, or 32-bit on a AMD64 in the k7 case).
My point was that the naming should reflect their current purpose, whatever that may be. "686" implies that it is the most appropriate kernel for all 686-based systems, which isn't necessarily true according to the above. > Fact of the matter is, I would be content having one SMP enabled kernel > for x86. The benefits are becoming fuzzy at best for different flavours, > given these reasons: Then please, please go ahead and make this change. It will save us hours of build time, hundreds of megabytes of archive space, untold bandwidth, etc. > 1) With SMP-Alt code, we no longer have a need for seperate SMP/UP > kernels. This code is included in stock kernels now. > > 2) With Generic Arch support (that's been there for a long time) in the > 386 kernel, the same code that does SMP-Alt also rewrites certain > portions of code to run better on the CPU on which it was booted, by > checking CPU flags and making adjustments based on this. We already get > this benefit in our 386 kernel, which is why I claim people generally > don't need to use the -686 or -k7 kernels. > > I would bet that a 486 generic arch, SMP enabled kernel would run within > 1% of any arch specific kernels we have. It would standardize the > kernels, and headers and make things hugely easy for maintenance. > > The only downside to this is that some legacy drivers (would have to get > a list) cannot be compiled with SMP support. They simply wont even load. > There's also one very popular driver that is known to be very unstable > under SMP (the rt2500 wireless driver). Please collect this list and publish it in the wiki; I'd like to look over it. Perhaps we can either fund a bounty to have these drivers brought up to snuff, or choose to drop them. But in terms of what we have today, what we want for the desktop is: On the desktop CD, we want a kernel which is appropriate for reasonably modern systems (implying SMP support). This, as I understand it, is what the -686 kernel is, so that's what we selected. On the alternate CD, we want a kernel which is more generic and can be used in the rare situations where the desktop kernel is not appropriate. There, we're using the -386 kernel. You said that you objected to using -686 this way; why? > So I think the goal, from my point of view at least, is that x86 in the > future will have three kernels: -generic, -server and -server-bigiron. That would be ideal; we can work out when/whether it's achievable based on the list of SMP-broken drivers. > This may also become the case for x86_64. Currently we have a > -amd64-generic that's SMP enabled, and I'm not sure the -k8 and -xeon > kernels are even needed. Please find a useful benchmark we can run to exercise the relevant code paths, so that we can get some numbers. If they're insignificant, let's definitely go ahead and do this. I'd love to see it happen. -- - mdz -- Edgy ubuntu-desktop depends on linux-headers-686 https://launchpad.net/bugs/56141 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
