Date: Tue, 15 Sep 2020 09:42:53 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: Charles Lecklider <freebsd-stable@lists.invis.net>, freebsd-stable@freebsd.org Subject: Re: Cannot find announcement that min supported i386 CPU is now i686 Message-ID: <35a18110-3252-2f53-ebae-b9a893776b62@grosbein.net> In-Reply-To: <d989bd39-df84-85de-c822-ef1ca3a70b10@lists.invis.net> References: <4460db23-9a29-7972-1b41-74585764a5d7@lists.invis.net> <20200831205136.GA15141@elch.exwg.net> <2986c4ef-6e73-50f9-215e-20e8a9793434@lists.invis.net> <6bd2c4f6-5ce1-5a0d-14b3-71831a0443f4@grosbein.net> <934c2a63-d3b0-dafb-08cf-8572bb313d03@lists.invis.net> <4873c4bd-abdc-f566-8038-e51c755b1222@grosbein.net> <d989bd39-df84-85de-c822-ef1ca3a70b10@lists.invis.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35a18110-3252-2f53-ebae-b9a893776b62>