|
|
Post by enigma9o7 on Jan 19, 2021 4:58:12 GMT
For past several days off and on I've been reading a long thread on debian mailing list in regards to i386 moving forward, and learned some interesting things I didn't know/understand before and thought I'd share some highlights.
For example in that message someone looked at current usage numbers of various kernels of debian users booting in the previous month, and found i386 the second most popular architecture, far more usage than all other arches that debian supports combined, with even arm being significantly less in 3rd place.
Then they further break down 32-bit kernels 3/4/5/6-86 and I learned a little bit about the differences - extensions like MMX SSE and PAE that add speed that weren't supported on the 1985 version original i386. etc. Apparently, using SSE provides significant performance improvement, and majority of debian i386 users are using the pae kernel with sse support which is basically Pentium 3 or newer and sometimes called i686. If I understood all that right, I think pae just lets you use more than 4gb ram but otherwise no improvement.
They also mention newest 32-bit Pentium 4 was made in 2007, and Pentium 3 are 20 years old, and many computers over 10 years old end up in landfill so very little reason to use new debian on something older than y2k even if you have it, cuz you can probably get something much better very cheap or free, and modern apps would run like crap.
Another issue brought up is about spectre and meltdown vulnerabilities, which were not mitigated for 32-bit intel until kernel version 4.19. Apparently these are vulnerabilities discovered a few years ago that affect most CPU newer than 1995 and without mitigations can make it possible for one app to see memory from another app which could be exploited.
So anyways, after reading that thread and making those observations, I feel like the next Bodhi Legacy should target Pentium III with pae. If you have even older machine that that you want to play with you probably dont want to use a full modern desktop environment anyway, even a light fast one like Moksha. I want Bodhi to be fast on legacy machines that people actually use with it, so I think we should include pae and sse etc. And we want people to feel secure if browsing etc so want kernel 4.19 or newer (used in debian 10 buster already).
And for the record, I do have a 2004 32-bit Pentium 4 2.8GHz 512MB running bodhi legacy (the reason I first installed linux and found this distro a few years ago in the first place), so I am familiar with how it runs on real hardware. I feel anything more than a cpu generation slower wouldn't be every fast with current Moksha anyway - so may as well make it as fast as possible for majority of people who should be using it, p3 and newer! My opinion, but I think sound logic. |
|
|
|
Post by fidoedidoe on Jan 19, 2021 14:59:31 GMT
So anyways, after reading that thread and making those observations, I feel like the next Bodhi Legacy should target Pentium III with pae. If you have even older machine that that you want to play with you probably dont want to use a full modern desktop environment anyway, even a light fast one like Moksha. I want Bodhi to be fast on legacy machines that people actually use with it, so I think we should include pae and sse etc. And we want people to feel secure if browsing etc so want kernel 4.19 or newer (used in debian 10 buster already). I found and adopted Bodhi because it supported 32-bit Non PAE processors and higher. For me, the initial reason was to help out my neighbour who had an old Windows XP laptop (upgraded to Windows 7), which was on it's knees with regards to performance (Dell Inspiron 1300 from memory). Bodhi Legacy was a perfect fit and given it's so lightweight it met/exceeded expectation and adoption to a Non Linux user went far better than expected (testament to Moksha Desktop). They even use that laptop with Audacity + USB dongle to convert Vinyl Records to MP3. Impressive for ancient 15+ year old hardware. Personally I'd argue having support for Non-PAE is a Jewel in the crown for Bodhi and I'd be very disappointed to see yet another linux distro fail to allow older technologies enjoy the benefits of "modern" desktop/OS feel and associated security (even if that doesn't mitigate Spectre variants etc - how many real world issues did that cause vs. how many PCs it slowed down via the fix?) FYI I've turned off spectre protection using kernel directive on my 7th Gen i7 so android ROM compile times are not impacted. I'd be interested in seeing the usage stats for Bodhi to see whether the "Legacy" Bodhi Community" is niche or mainstream and what sub divisions of Non-PAE/PAE supporting CPU's they fall into. It all feels somewhat subjective without supporting stats. |
|
|
|
Post by Hippytaff on Jan 19, 2021 15:37:11 GMT
I'd be interested in seeing the usage stats for Bodhi to see whether the "Legacy" Bodhi Community" is niche or mainstream and what sub divisions of Non-PAE/PAE supporting CPU's they fall into. It all feels somewhat subjective without supporting stats. Feel free to set up a poll. I’d be interested to see that too. Currently building a moksha Debian 32bit in vm to have a play, but I agree to your points re non-pae support. |
|
|
|
Post by enigma9o7 on Jan 19, 2021 17:15:34 GMT
Yeah I think I misunderstood the pae thing anyway. I first read it affects speed significantly, but later learned it seems like that doesnt speed anythiing up at all, just gives support for more than 4gb of ram. So not actually important, anyone with more than 4gb of ram probably has 64bit cpu anyway. Its he SSE2 that speeds things up.
|
|
|
|
Post by nuihc88 on Feb 20, 2021 22:21:28 GMT
I have been researching custom kernels like Zen/Liquorix & XanMod and how to best compile them for past few months in hopes of improving the energy efficiency and responsiveness of my Asus eeePC 1005HA-H while also adding PHC-Intel module for undervolting the CPU, backporting iwlwifi for adding support for a intel AX200 WiFi+BT card and making the special ACPI keys work correctly via acpi-eeepc. Saw this thread and thought i might as well share my research up to now in case it helps with improving future versions of one of the few remaining 32bit distros out there...
First off: it's fairly rare for 32bit Linux desktops/laptops to need more than 4GB of memory, however recompiling a kernel with PAE-support is basically just a few .config switches and hours of waiting away. In theory replacing 'CONFIG_HIGHMEM4G=y' line in .config file with 'CONFIG_HIGHMEM64G=y' & 'CONFIG_X86_PAE=y' lines should suffice, although i've seen a bunch of additional platform specific optimizations in configuration-files of performance optimized kernels like Liquorix.
Another important thing to note is that you can turn off most Spectre/Meltdown-mitigations just by addding 'mitigations=off' to 'GRUB_CMDLINE_LINUX_DEFAULT=""' line in '/etc/default/grub'. I read that this option has already been backported to 4.19.43 and it should be possible to confirm whether mitigations are then disabled or enabled by running 'lscpu', although on my system that information seems to not be displayed for some reason. Furthermore Linux-kernel developers have been busy trying to "mitigate" the performance hits that their vulnerability mitigations have caused so some performance benchmarks have actually gone up as a result of increased scrutiny, however i would still advice against using 5.** on 32bit systems as new kernels seem to be having trouble building some 32bit modules correctly.
In summary, for best performance i would recommend applying new patches on top of XanMod 4.20 kernel, building it using .config copied from the target distro's latest non-PAE kernel with tweaks added from my lists below and then running menuconfig to clean out any incompatible entries and double-check things manually before compiling and then finally always running the resulting kernel with mitigations disabled through grub.
Finally here are some fairly generic tweaks for improving the efficiency of 4.** kernels:
# Trade-off Placebo-Security for Speed:
CONFIG_RANDOM_TRUST_CPU=y
# Energy-Efficiency Tweaks:
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_RCU_NOCB_CPU=y
CONFIG_HZ_100=y
CONFIG_HZ=100 # higher latency; less overhead.
# Responsiveness Tweaks:
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_DELAY=100 # Arbitrary, i've seen values 0 to 500 recommended.
# LowLatency/PreEmptive Tweaks:
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_IRQ_FORCED_THREADING_DEFAULT=y
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPT_RCU=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000 # lower latency; more overhead.
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_CEC_PIN=y
# CONFIG_CEC_PIN_ERROR_INJ is not set
CONFIG_CEC_GPIO=m
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_LATENCYTOP=y
# CONFIG_PREEMPT_TRACER is not set
PS. Note that 'CONFIG_HZ_100=y' from Energy-Efficiency Tweaks and 'CONFIG_HZ_1000=y' from LowLatency/PreEmptive Tweaks as well as the lines directly below them conflict with each other; personally i would pick 100 over 1000 for older computers in order to reduce system overhead.
PPS. The last kernel version to include no mitigations at all was 4.14.
|
|
