Charles Lecklider
2020-Sep-14 05:08 UTC
Cannot find announcement that min supported i386 CPU is now i686
On 2020-09-14 04:41, Eugene Grosbein wrote:> Build time for modern FreeBSD version is too gross and needs way too much memory, > so I stopped building image for my i586 hardware "in place" quite long ago.It would take about a week to compile, but since it was stable <11.4 I didn't really care.> I use my i7-based desktop to build NanoBSD image for its upgrade, it works just fine > by default setting ARCH/TARGET_ARCH to i386 and correct CPUTYPE.I tried that on my workstation (dual Xeon, lots of RAM) but couldn't get it to compile for i586 - various things kept bailing out. It would compile i386 for i686, but not i586. Have you tried it with 11.4?>> Don't try -Os or -Oz (which really do help on a real i586) - ZFS will >> wedge quickly. > > Currently i586-class CPU needs as many speed improvements as possible > and I was told that -Os might drop performance comparing with -O2, > so why bother?It depends on your workload. This machine spends most of its life running rsync over ssh, so having more useful code in L2 cache makes a difference even if it takes a few more clock cycles to run. The bottleneck is IO - mainly disc, but also network (way better with polling - don't know why it's not in GENERIC) so those extra clock cycles aren't as important. If you're doing real number-crunching stuff with it, a) why?!, and b) yes, -O2 would be better.>> 11.4 i386 doesn't honour `vfs.zfs.arc_max` in any meaningful way >> resulting in one of the `find`s in periodic security wedging ZFS. > > Been there, seen that. The problem pre-dates 11.x series and appeared in 10.x. > It was much better in times of 9.x, though.Yes, I've also seen it before, but 11.4 is particularly egregious with its disregard on i386 - amd64 is behaving itself on everything I've tried.>> options KSTACK_PAGES=4 > > This is default for 12.x/i386 but was not merged to stable/11.That's good to know.> You might find useful these also: > > vfs.zfs.vdev.cache.size="8M" > vfs.zfs.prefetch_disable="1"Prefetch is disabled on i386 by default; I played with the vdev cache size too but it made no discernable difference.> And for kernel config: > > options KVA_PAGES=512 > > This makes ZFS more stable giving it bigger kernel virtual area with less utilization for it.Yes, that's the theory, but when I tried it on earlier versions the kernel would just blow up on boot. I may try it again next time I update the kernel.>> TL;DR: I'd avoid 11.4 i386 as it doesn't appear to have been tested on >> i486/i586 at all. > > Finally I gave up running ZFS for vmem-contrained systems, > e.g. I moved my i386 virtual machines that benefit from ZFS compression to amd64.Oh, sure - I'd never dream of doing anything fancy with ZFS on this machine - it just does backups. My point was that 11.4 doesn't "feel" right - it doesn't seem to have been tested on <i686 at all, not even virtually. I've run every version of FreeBSD since 2.x - some "feel" right, some "feel" dodgy (5.3, 6.x, some 8.x IIRC). On amd64 it "feels" great, but I don't really trust it on i386. -C
Eugene Grosbein
2020-Sep-15 02:42 UTC
Cannot find announcement that min supported i386 CPU is now i686
14.09.2020 12:08, Charles Lecklider via freebsd-stable wrote:> On 2020-09-14 04:41, Eugene Grosbein wrote: >> Build time for modern FreeBSD version is too gross and needs way too much memory, >> so I stopped building image for my i586 hardware "in place" quite long ago. > > It would take about a week to compile, but since it was stable <11.4 I > didn't really care. > >> I use my i7-based desktop to build NanoBSD image for its upgrade, it works just fine >> by default setting ARCH/TARGET_ARCH to i386 and correct CPUTYPE. > > I tried that on my workstation (dual Xeon, lots of RAM) but couldn't get > it to compile for i586 - various things kept bailing out. It would > compile i386 for i686, but not i586. Have you tried it with 11.4?Just updated that my i586 AMD Geode system upto latest 11.4-STABLE, all went OK. I build it with standard nanobsd(8) utility in base system, my build configuration contains: NANO_PMAKE="make -j3" NANO_KERNEL=GWOLD CONF_BUILD=' TARGET=i386 TARGET_ARCH=i386 NANO_ARCH=i386 CPUTYPE?=k6-3 ... ' And kernel configuration has: machine i386 cpu I586_CPU cpu I686_CPU options CPU_GEODE options CPU_SOEKRIS options SCHED_4BSD ... For UP system, I find SCHED_4BSD behave better than default SCHED_ULE.>>> Don't try -Os or -Oz (which really do help on a real i586) - ZFS will >>> wedge quickly. >> >> Currently i586-class CPU needs as many speed improvements as possible >> and I was told that -Os might drop performance comparing with -O2, >> so why bother? > > It depends on your workload. This machine spends most of its life > running rsync over ssh, so having more useful code in L2 cache makes a > difference even if it takes a few more clock cycles to run. The > bottleneck is IO - mainly disc, but also network (way better with > polling - don't know why it's not in GENERIC) so those extra clock > cycles aren't as important. > > If you're doing real number-crunching stuff with it, a) why?!,Isn't ssh encryption/decryption "real" number-crunching? My i586 system did IPSec encryption for tunnels and despite of having AES-CBC-128 onboard hardware accelerator suitable for IPSec, it was quite limited by CPU horsepower, so I used hmac-md5 instead of SHA variants to speed-up things a bit and still, it was able to saturate 100Mbps with unencrypted PPPoE+ipfw nat but only 33Mbps with IPSec AES+MD5 and less with SHA.> and b) yes, -O2 would be better. > >>> 11.4 i386 doesn't honour `vfs.zfs.arc_max` in any meaningful way >>> resulting in one of the `find`s in periodic security wedging ZFS. >> >> Been there, seen that. The problem pre-dates 11.x series and appeared in 10.x. >> It was much better in times of 9.x, though. > > Yes, I've also seen it before, but 11.4 is particularly egregious with > its disregard on i386 - amd64 is behaving itself on everything I've tried. > >>> options KSTACK_PAGES=4 >> >> This is default for 12.x/i386 but was not merged to stable/11. > > That's good to know. > >> You might find useful these also: >> >> vfs.zfs.vdev.cache.size="8M" >> vfs.zfs.prefetch_disable="1" > > Prefetch is disabled on i386 by default; I played with the vdev cache > size too but it made no discernable difference. > >> And for kernel config: >> >> options KVA_PAGES=512 >> >> This makes ZFS more stable giving it bigger kernel virtual area with less utilization for it. > > Yes, that's the theory, but when I tried it on earlier versions the > kernel would just blow up on boot. I may try it again next time I update > the kernel.It worked for me with KVA_PAGES=768 even, so kernel and ZFS had 3GB for virtual area and only 1GB for userland but that was i386 virtual machine with 512M or 1GB RAM only (cheapest hoster provided some years ago), so 1GB for userland was just fine :-)>>> TL;DR: I'd avoid 11.4 i386 as it doesn't appear to have been tested on >>> i486/i586 at all. >> >> Finally I gave up running ZFS for vmem-contrained systems, >> e.g. I moved my i386 virtual machines that benefit from ZFS compression to amd64. > > Oh, sure - I'd never dream of doing anything fancy with ZFS on this > machine - it just does backups. > > My point was that 11.4 doesn't "feel" right - it doesn't seem to have > been tested on <i686 at all, not even virtually. I've run every version > of FreeBSD since 2.x - some "feel" right, some "feel" dodgy (5.3, 6.x, > some 8.x IIRC). On amd64 it "feels" great, but I don't really trust it > on i386.Can't see any difference with early 11.x versions but I build it all by myself for many major releases.