Date: Mon, 7 Oct 2019 11:20:05 -0600 From: Warner Losh <imp@bsdimp.com> To: Julian Elischer <julian@freebsd.org> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, Lev Serebryakov <lev@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: New CPUTYPE default for i386 port Message-ID: <CANCZdfrH23UkyXgLYYKpw2kmYFCL7Hi1W-Vpi3EDahzVp_7gFA@mail.gmail.com> In-Reply-To: <390dc131-bd71-cba8-76c1-df30ed721f4f@freebsd.org> References: <CANCZdfqL2LD_Yu49XMid-G21w-HKSDA4yW4Wi_uEW37rAG9E2Q@mail.gmail.com> <201910060322.x963Mwo1065732@gndrsh.dnsmgr.net> <CANCZdfra0r=GYF5KSHqGuhNQq6RTXCBu8r9j3YfGc4iVmTsNag@mail.gmail.com> <89501a69-ea37-7016-5ccb-286ff65b2e2a@FreeBSD.org> <18250.1570457337@critter.freebsd.dk> <CANCZdfr00NFPdbnOdaXoZPbbj%2BVJVRXmQcoD3Y=ewS78wmkL2A@mail.gmail.com> <390dc131-bd71-cba8-76c1-df30ed721f4f@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 7, 2019 at 10:50 AM Julian Elischer <julian@freebsd.org> wrote: > On 10/7/19 9:30 AM, Warner Losh wrote: > > On Mon, Oct 7, 2019 at 8:09 AM Poul-Henning Kamp <phk@phk.freebsd.dk> > wrote: > > > >> The 4801s, on the other hand, seems to be indestructible... > >> > > So the question we need to answer, that Rod brought up, is "Are there > > enough machines that can boot FreeBSD release images that would otherwise > > fail with some weird error that we need to deploy counter measures"? > > > > I did a survey of the old 'desktop / server' hardware available on EBAY. > If > > you look at all Pentiums, then the number of machines that (a) are new > > enough to support CDROM booting and (b) have enough memory are << 1% (I > > found 1 out of 250 that I looked at). So from that perspective, things > are > > fine: machines that might be able to boot today's 13 snapshots are quite > > rare in this space.... rare enough to not worry apart from release notes. > > There's likely some level of error in this survey, but the bound of > > uncertainty here is such that more accurate data likely wouldn't change > the > > conclusion. > > > > However, there's a number of embedded products that were so popular in > the > > community that there might be people that want to run 13.0 when it is > > released. That's a fair point that I'd not considered. > > > > The question becomes: are people using only the release images on these > > boxes? Or are they rolling their own? > > > > If they are rolling their own, release notes is all that's needed. > > > > If they are using the release images, then we may want to give at least > > some warning. These machines are MBR/GPT BIOS booted. So we could put a > > warning into boot2 (maybe room), gptboot (plenty of room) or cdboot (has > > room) that would trigger on 486 and 586 machines. I'd want to turn it off > > were I deploying these machines, or off in general outside the release > env. > > It would limit the amount of code we'd have to compile specially, but > would > > be the most reliable way of getting a message to any affected user. > That's > > likely the best we could do here. > > I think the answer is that as long as we can still generate the > images, the default is not so important. > That's my position :) > But the size of system needed to actually generate such a system with > the modern compiler etc may make self hosting a bit of an issue. > Unfortunately I deleted the very first post in the thread, so I can't > remember the reason he gave but I presume that the usual reasons > apply. Compiling as a pre-pentum results in reduced performance for > any machine built inthe last 20 years. The only comment that I haven't > seen made is that pre-686 class machines are possibly not dropping as > a percentage f 32 bit chipsets as nearly all machines sold for > desktop/taptop use these days are 64 bit, meaning that 32 bit is > limited to embedded, and I can not say what percentage of modern 32 > bit systems are the ultra-low power pre-686 types, as I have not been > following that market. > We've seen a *HUGE* drop-off in the 32-bit i386 vs 64-bit amd64 kernels as reported to external databases I can query in the past few years. It's clear that a substantial majority have been replaced in the past 5 years. It's to the point that i386 is in the ~10% of amd64 range and falling fast. Getting more nuance than that, however, is hard given we have no good data sources. I've not done a CPU analysis over time, but I suspect that the percentage of 586 class CPUs in that shrinking sliver is <<1% and likely <0.1%, with 486 class machines being 100x rarer (1 machine in 2018 running 4.3 and the other machines are > 10 years old: 2 whistles running 7.0, 1 soekris 4511 and one 486 frankenstein in 2004). Quick numbers show 8 586 dmesgs (ALX or Soekris) in the last 3 years in nycbug database, and maybe 70-80 i386 machines and maybe 800-1000 amd64 boxes (didn't actually count, but estimated). NYCBUG data tends to exaggerate the snowflakes popularity due to its nature of being a place to upload the weird and unique machines (rather than all of them). But even so, these machines are somewhat rare among the rarities. The data suggests that we could turn off 486 entirely and nobody would notice. > I run a soekris 5501 but i do have alternatives, and it is running 9.1 > I think. I have no real plans to massively upgrade it, and if I did I > would not compile on that.. it would take a month including ports. > Yea. We've not been quickly self-hosting on this class of machines since the move to clang. I have a 32-bit laptop with a ~1GHz Pentium-M and 512MB of ram that takes ~36 hours to do a buildworld and another 2 hours or more to do a build-kernel. And that machine is quite a bit beefier than the Soekris 5501... :( Warner Julian > > > > > Warner > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrH23UkyXgLYYKpw2kmYFCL7Hi1W-Vpi3EDahzVp_7gFA>