| Message ID | 20241204103042.1904639-9-arnd@kernel.org (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | x86: 32-bit cleanups | expand |
+Cc: Ferry On Wed, Dec 4, 2024 at 12:31 PM Arnd Bergmann <arnd@kernel.org> wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > The X86_INTEL_MID code was originally introduced for the > 32-bit Moorestown/Medfield/Clovertrail platform, later the 64-bit > Merrifield/Moorefield variant got added, but the final variant got --> variants were > Morganfield/Broxton 14nm chips were canceled before they hit > the market. Inaccurate. "Broxton for Mobile", and not "Broxton" in general. > To help users understand what the option actually refers to, > update the help text, and make it a hard dependency on 64-bit > kernels. While they could theoretically run a 32-bit kernel, > the devices originally shipped with 64-bit one in 2015, so that > was proabably never tested. probably It's all other way around (from SW point of view). For unknown reasons Intel decided to release only 32-bit SW and it became the only thing that was heavily tested (despite misunderstanding by some developers that pointed finger to the HW without researching the issue that appears to be purely software in a few cases) _that_ time. Starting ca. 2017 I enabled 64-bit for Merrifield and from then it's being used by both 32- and 64-bit builds. I'm totally fine to drop 32-bit defaults for Merrifield/Moorefield, but let's hear Ferry who might/may still have a use case for that. ... > - Moorestown MID devices FTR, a year or so ago it was a (weak) interest to revive Medfield, but I think it would require too much work even for the person who is quite familiar with HW, U-Boot, and Linux kernel, so it is most unlikely to happen. ... > Select to build a kernel capable of supporting Intel MID (Mobile > Internet Device) platform systems which do not have the PCI legacy > - interfaces. If you are building for a PC class system say N here. > + interfaces. > + > + The only supported devices are the 22nm Merrified (Z34xx) and > + Moorefield (Z35xx) SoC used in Android devices such as the > + Asus Zenfone 2, Asus FonePad 8 and Dell Venue 7. The list is missing the Intel Edison DIY platform which is probably the main user of Intel MID kernels nowadays. ... > - Intel MID platforms are based on an Intel processor and chipset which > - consume less power than most of the x86 derivatives. Why remove this? AFAIK it states the truth.
On Wed, Dec 4, 2024, at 19:55, Andy Shevchenko wrote: > +Cc: Ferry > > On Wed, Dec 4, 2024 at 12:31 PM Arnd Bergmann <arnd@kernel.org> wrote: >> >> From: Arnd Bergmann <arnd@arndb.de> >> >> The X86_INTEL_MID code was originally introduced for the >> 32-bit Moorestown/Medfield/Clovertrail platform, later the 64-bit >> Merrifield/Moorefield variant got added, but the final > > variant got --> variants were Fixed >> Morganfield/Broxton 14nm chips were canceled before they hit >> the market. > > Inaccurate. "Broxton for Mobile", and not "Broxton" in general. Changed to "but the final Morganfield 14nm platform was canceled before it hit the market" >> To help users understand what the option actually refers to, >> update the help text, and make it a hard dependency on 64-bit >> kernels. While they could theoretically run a 32-bit kernel, >> the devices originally shipped with 64-bit one in 2015, so that >> was proabably never tested. > > probably Fixed. > It's all other way around (from SW point of view). For unknown reasons > Intel decided to release only 32-bit SW and it became the only thing > that was heavily tested (despite misunderstanding by some developers > that pointed finger to the HW without researching the issue that > appears to be purely software in a few cases) _that_ time. Starting > ca. 2017 I enabled 64-bit for Merrifield and from then it's being used > by both 32- and 64-bit builds. > > I'm totally fine to drop 32-bit defaults for Merrifield/Moorefield, > but let's hear Ferry who might/may still have a use case for that. Ok. I tried to find the oldest Android image and saw it used a 64-bit kernel, but that must have been after your work then. > >> - Moorestown MID devices > > FTR, a year or so ago it was a (weak) interest to revive Medfield, but > I think it would require too much work even for the person who is > quite familiar with HW, U-Boot, and Linux kernel, so it is most > unlikely to happen. Ok. >> + >> + The only supported devices are the 22nm Merrified (Z34xx) and >> + Moorefield (Z35xx) SoC used in Android devices such as the >> + Asus Zenfone 2, Asus FonePad 8 and Dell Venue 7. > > The list is missing the Intel Edison DIY platform which is probably > the main user of Intel MID kernels nowadays. Ah, that explains a lot ;-) Changed now to The only supported devices are the 22nm Merrified (Z34xx) and Moorefield (Z35xx) SoC used in the Intel Edison board and a small number of Android devices such as the Asus Zenfone 2, Asus FonePad 8 and Dell Venue 7. > ... > >> - Intel MID platforms are based on an Intel processor and chipset which >> - consume less power than most of the x86 derivatives. > > Why remove this? AFAIK it states the truth. It seemed irrelevant for users that configure the kernel. I've put it back now. Thanks for the review! Arnd
On Wed, Dec 04, 2024 at 09:38:05PM +0100, Arnd Bergmann wrote: > On Wed, Dec 4, 2024, at 19:55, Andy Shevchenko wrote: > > On Wed, Dec 4, 2024 at 12:31 PM Arnd Bergmann <arnd@kernel.org> wrote: ... > > It's all other way around (from SW point of view). For unknown reasons > > Intel decided to release only 32-bit SW and it became the only thing > > that was heavily tested (despite misunderstanding by some developers > > that pointed finger to the HW without researching the issue that > > appears to be purely software in a few cases) _that_ time. Starting > > ca. 2017 I enabled 64-bit for Merrifield and from then it's being used > > by both 32- and 64-bit builds. > > > > I'm totally fine to drop 32-bit defaults for Merrifield/Moorefield, > > but let's hear Ferry who might/may still have a use case for that. > > Ok. I tried to find the oldest Android image and saw it used a 64-bit > kernel, but that must have been after your work then. I stand up corrected, what I said is related to Merrifield, Moorefield may have 64-bit users on the phones from day 1, though. ... > Changed now to > > The only supported devices are the 22nm Merrified (Z34xx) and > Moorefield (Z35xx) SoC used in the Intel Edison board and > a small number of Android devices such as the Asus Zenfone 2, > Asus FonePad 8 and Dell Venue 7. LGTM, thanks! ... > >> - Intel MID platforms are based on an Intel processor and chipset which > >> - consume less power than most of the x86 derivatives. > > > > Why remove this? AFAIK it states the truth. > > It seemed irrelevant for users that configure the kernel. I've > put it back now. It might be, but it was already there. Thanks for leaving it untouched.
Hi, Op 04-12-2024 om 19:55 schreef Andy Shevchenko: > +Cc: Ferry > > On Wed, Dec 4, 2024 at 12:31 PM Arnd Bergmann <arnd@kernel.org> wrote: >> From: Arnd Bergmann <arnd@arndb.de> >> >> The X86_INTEL_MID code was originally introduced for the >> 32-bit Moorestown/Medfield/Clovertrail platform, later the 64-bit >> Merrifield/Moorefield variant got added, but the final > variant got --> variants were > >> Morganfield/Broxton 14nm chips were canceled before they hit >> the market. > Inaccurate. "Broxton for Mobile", and not "Broxton" in general. > > >> To help users understand what the option actually refers to, >> update the help text, and make it a hard dependency on 64-bit >> kernels. While they could theoretically run a 32-bit kernel, >> the devices originally shipped with 64-bit one in 2015, so that >> was proabably never tested. > probably > > It's all other way around (from SW point of view). For unknown reasons > Intel decided to release only 32-bit SW and it became the only thing > that was heavily tested (despite misunderstanding by some developers > that pointed finger to the HW without researching the issue that > appears to be purely software in a few cases) _that_ time. Starting > ca. 2017 I enabled 64-bit for Merrifield and from then it's being used > by both 32- and 64-bit builds. > > I'm totally fine to drop 32-bit defaults for Merrifield/Moorefield, > but let's hear Ferry who might/may still have a use case for that. Do to the design of SLM if found (and it is also documented in Intel's HW documentation) that there is a penalty introduced when executing certain instructions in 64b mode. The one I found is crc32di, running slower than 2 crc32si in series. Then there are other instructions seem to runs faster in 64b mode. And there is of course the usual limited memory space than could benefit for 32b mode. I never tried the mixed (x86_32?) mode. But I am building and testing both i686 and x86_64 for each Edison image. I think that should at minimum be useful to catch 32b errors in the kernel in certain areas (shared with other 32b archs. So, I would prefer 32b support for this platform to continue. > ... > >> - Moorestown MID devices > FTR, a year or so ago it was a (weak) interest to revive Medfield, but > I think it would require too much work even for the person who is > quite familiar with HW, U-Boot, and Linux kernel, so it is most > unlikely to happen. > > ... > >> Select to build a kernel capable of supporting Intel MID (Mobile >> Internet Device) platform systems which do not have the PCI legacy >> - interfaces. If you are building for a PC class system say N here. >> + interfaces. >> + >> + The only supported devices are the 22nm Merrified (Z34xx) and >> + Moorefield (Z35xx) SoC used in Android devices such as the >> + Asus Zenfone 2, Asus FonePad 8 and Dell Venue 7. > The list is missing the Intel Edison DIY platform which is probably > the main user of Intel MID kernels nowadays. Despite the Dell Venue 7 originally running a 32b Android kernel (I think), I got it run linux/Yocto in 64 bits. > ... > >> - Intel MID platforms are based on an Intel processor and chipset which >> - consume less power than most of the x86 derivatives. > Why remove this? AFAIK it states the truth. > >
On Fri, Dec 6, 2024, at 12:23, Ferry Toth wrote: > Op 04-12-2024 om 19:55 schreef Andy Shevchenko: >> >> It's all other way around (from SW point of view). For unknown reasons >> Intel decided to release only 32-bit SW and it became the only thing >> that was heavily tested (despite misunderstanding by some developers >> that pointed finger to the HW without researching the issue that >> appears to be purely software in a few cases) _that_ time. Starting >> ca. 2017 I enabled 64-bit for Merrifield and from then it's being used >> by both 32- and 64-bit builds. >> >> I'm totally fine to drop 32-bit defaults for Merrifield/Moorefield, >> but let's hear Ferry who might/may still have a use case for that. > > Do to the design of SLM if found (and it is also documented in Intel's > HW documentation) > > that there is a penalty introduced when executing certain instructions > in 64b mode. The one I found > > is crc32di, running slower than 2 crc32si in series. Then there are > other instructions seem to runs faster in 64b mode. > > And there is of course the usual limited memory space than could benefit > for 32b mode. I never tried the mixed (x86_32?) > > mode. But I am building and testing both i686 and x86_64 for each Edison > image. Hi Ferry, Thanks a lot for the detailed reply, this is exactly the kind of information I was hoping to get out of my series, in particular since we have a lot of the same tradeoffs on low-end 64-bit Arm platforms, and I've been trying to push users toward running 64-bit kernels on those. I generally think that it makes a lot of sense to run 32-bit userspace on memory limited devices, in particular with less than 512MB, but it's often still useful on devices with 1GB. Running a 32-bit kernel is usually not worth it if you can avoid it, and with 1GB of RAM you definitely run into limits either from using HIGHMEM (with CONFIG_VMSPLIT_3G) or in user addressing (with any other VMPLIT_*), in addition to the 32-bit kernels just being less well maintained and missing security features. Using a 64-bit kernel with CONFIG_COMPAT for 32-bit userspace tends to be the best combination for a large number of embedded workloads. As a rough estimate on Arm hardware, I found that a 64-bit kernel tends to use close to twice the amount of RAM for itself (vmlinux, slab caches, page tables, mem_map[]) compared to a 32-bit kernel, but this should be no more than 10-20% of the total RAM for sensible workloads as all the interesting bits happen in userland. I expect the numbers to be similar for x86, but have not looked in detail. In userspace there is more variation depending on the type of application: the base system has a similar 2x ratio, but once you get into data intensive tasks (file server, networking, image/video processing, ...) the overhead of 64-bit userspace is lower because the size of the actual data is the same on both. For the specific case of the crc32di instruction, I suspect the in-kernel version of this can be trivially changed like diff --git a/arch/x86/crypto/crc32c-intel_glue.c b/arch/x86/crypto/crc32c-intel_glue.c index 52c5d47ef5a1..60b9b3cab679 100644 --- a/arch/x86/crypto/crc32c-intel_glue.c +++ b/arch/x86/crypto/crc32c-intel_glue.c @@ -60,10 +60,10 @@ static u32 __pure crc32c_intel_le_hw(u32 crc, unsigned char const *p, size_t len { unsigned int iquotient = len / SCALE_F; unsigned int iremainder = len % SCALE_F; - unsigned long *ptmp = (unsigned long *)p; + unsigned int *ptmp = (unsigned int *)p; while (iquotient--) { - asm(CRC32_INST + asm("crc32l %1, %0" : "+r" (crc) : "rm" (*ptmp)); ptmp++; } to get you the faster version, plus some form of configurability to make sure other CPUs still get the crc32q version by default. > I think that should at minimum be useful to catch 32b errors in the > kernel in certain areas (shared with other 32b > archs. So, I would prefer 32b support for this platform to continue. I can certainly see this both ways, on the one hand I do care a lot about 32-bit Arm platforms and appreciate the help in finding issues on 32-bit kernels. On the other hand I really don't want anyone to waste time testing something that should never be used in practice and keeping a feature in the kernel only for the purpose of regression testing that feature. The platform is also special enough that I don't see testing it in 32-bit mode as particularly helpful to others, and it's unlikely to catch bugs that testing in KVM won't. Testing your 32-bit userland with a 64-bit kernel would be helpful of course to ensure it keeps working for anyone that had been using 32-bit kernel+userspace if we drop 32-bit kernel support for it. One related idea that I've discussed before is to have 32-bit kernels refuse to boot on 64-bit hardware and instead print the URL of a wiki page to explain all of the above. There would probably have to be whitelist of platforms that are buggy in 64-bit mode, and a command line option to revert back to the previous behavior to allow testing. Arnd
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index d8a8bf9ea9b9..fa6dd9ec4bdf 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -544,12 +544,12 @@ config X86_EXTENDED_PLATFORM RDC R-321x SoC SGI 320/540 (Visual Workstation) STA2X11-based (e.g. Northville) - Moorestown MID devices 64-bit platforms (CONFIG_64BIT=y): Numascale NumaChip ScaleMP vSMP SGI Ultraviolet + Merrifield/Moorefield MID devices If you have one of these systems, or if you want to build a generic distribution kernel, say Y here - otherwise say N. @@ -621,11 +621,11 @@ config X86_INTEL_CE boxes and media devices. config X86_INTEL_MID - bool "Intel MID platform support" + bool "Intel Z34xx/Z35xx MID platform support" depends on X86_EXTENDED_PLATFORM depends on X86_PLATFORM_DEVICES depends on PCI - depends on X86_64 || (PCI_GOANY && X86_32) + depends on X86_64 depends on X86_IO_APIC select I2C select DW_APB_TIMER @@ -633,10 +633,14 @@ config X86_INTEL_MID help Select to build a kernel capable of supporting Intel MID (Mobile Internet Device) platform systems which do not have the PCI legacy - interfaces. If you are building for a PC class system say N here. + interfaces. + + The only supported devices are the 22nm Merrified (Z34xx) and + Moorefield (Z35xx) SoC used in Android devices such as the + Asus Zenfone 2, Asus FonePad 8 and Dell Venue 7. - Intel MID platforms are based on an Intel processor and chipset which - consume less power than most of the x86 derivatives. + If you are building for a PC class system or non-MID tablet + SoCs like Bay Trail (Z36xx/Z37xx), say N here. config X86_INTEL_QUARK bool "Intel Quark platform support" diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c index de001b2146ab..4f69239556e4 100644 --- a/arch/x86/kernel/head32.c +++ b/arch/x86/kernel/head32.c @@ -65,9 +65,6 @@ asmlinkage __visible void __init __noreturn i386_start_kernel(void) /* Call the subarch specific early setup function */ switch (boot_params.hdr.hardware_subarch) { - case X86_SUBARCH_INTEL_MID: - x86_intel_mid_early_setup(); - break; case X86_SUBARCH_CE4100: x86_ce4100_early_setup(); break;