Date: Fri, 7 Dec 2012 16:31:54 -0700 From: Warner Losh <imp@bsdimp.com> To: Alfred Perlstein <bright@mu.org> Cc: Adrian Chadd <adrian@freebsd.org>, Alfred Perlstein <alfred@freebsd.org>, Andre Oppermann <andre@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: svn commit: r243594 - head/sys/netinet Message-ID: <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> In-Reply-To: <50C278B0.3040107@mu.org> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <AC499CCF-3812-4CA9-929C-05AA4C39F223@mu.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <CAJ-Vmo=okfoDzUSBJ%2B1=iq44EaNw_uOWCOTB-7TVU6%2BdFZeFyA@mail.gmail.com> <50C278B0.3040107@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 7, 2012, at 4:16 PM, Alfred Perlstein wrote: > I'm sorry Adrian, the difference between installing a server OS with a = CDROM/USBkey is vastly different than the type of user that is using an = embedded board. >=20 > The embedded user will be doing so over some weird install media, = using serial and all kinds of other things. >=20 > If you have tunables or compile time options you want to distribute on = MIPS/arm, then by all means force TCBHASH to 512. >=20 > You can easily make a "small memory kernel include file" for this. >=20 > Please do it. Please make ARM/MIPS/whatever better for you. >=20 > As far as some pipe-dream runtime tuning, all singing/dancing thingy = to make everything happy, well that doesn't exist. >=20 > So either write it, or take a pragmatic approach and fix your = platforms and please stop standing in the way of server OS. Nobody is standing in the way of the server OS when we point out that = the tuning for the server actively breaks small systems. That's called = bug reporting, something any sane organization would reply with "oh, = let's fix the bug" rather than a raft of finger pointing. The bug here = is that the system will not boot at all for lower memory configurations. = "Tuning for servers" isn't a get-out-of-jail-free card for this bug. Seriously though, we should have these kinds of tuning in files that = different platforms include or not depending on what the system is being = tuned for. We can even put them in GENERIC for amd64 if you want, = that's fine so the out-of-the-box experience is tuned for big-iron = servers. But to require all hardware that isn't big iron to hand-tune = dozens of parameters (or even just a dozen) is going to end in tears. To summarize: we agree on the goal, and disagree that the current = approach is sane, Warner > -Alfred >=20 > On 12/7/12 3:03 PM, Adrian Chadd wrote: >> Alfred, >>=20 >> I can make the same argument about "out of the box" experiences with >> Linux and FreeBSD on embedded. >>=20 >> If the embedded experience out of the box "isn't as good or better" >> than Linux, people will go with Linux. >>=20 >> I think you're only really considering the server space. The bigger >> issue here is "people who are changing the algorithms are making >> different but same mistakes as the earlier algorithms", which is >> "works for me,". >>=20 >> Solving a lot of this stuff for both small and large scale doesn't >> _have_ to be too difficult. The current attempt at making things = nicer >> for the server space has shown it doesn't work for the non-server >> space. That means the problem isn't fully understood. >>=20 >> Honestly, I'd rather see a lot of this auto-tuning be done at = run-time >> rather than compile or boot time, with some relatively smart tools >> that can look at the system specifications and current mbuf/allocator >> configuration, look at some historical information about allocations, >> and make suggestions about what can be tuned. >>=20 >> You can _also_ make the defaults work well on the low end and the = high >> end. The tool(s) shouldn't be _instead_ of that, it should be _with_ >> that. >>=20 >> Let's try to understand the problem space a bit better before we = start >> changing things some more. It's obvious from the recent changes that >> people don't understand the bigger picture. >>=20 >>=20 >>=20 >> Adrian >>=20 >=20 > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://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?52564974-563C-499F-9860-ADACA0DD22CE>