Date: Mon, 14 Sep 2020 06:08:36 +0100 From: Charles Lecklider <freebsd-stable@lists.invis.net> To: freebsd-stable@freebsd.org Subject: Re: Cannot find announcement that min supported i386 CPU is now i686 Message-ID: <d989bd39-df84-85de-c822-ef1ca3a70b10@lists.invis.net> In-Reply-To: <4873c4bd-abdc-f566-8038-e51c755b1222@grosbein.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d989bd39-df84-85de-c822-ef1ca3a70b10>