Date: Fri, 07 Dec 2012 15:16:00 -0800 From: Alfred Perlstein <bright@mu.org> To: Adrian Chadd <adrian@freebsd.org> Cc: Alfred Perlstein <alfred@freebsd.org>, Andre Oppermann <andre@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: svn commit: r243594 - head/sys/netinet Message-ID: <50C278B0.3040107@mu.org> In-Reply-To: <CAJ-Vmo=okfoDzUSBJ%2B1=iq44EaNw_uOWCOTB-7TVU6%2BdFZeFyA@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. The embedded user will be doing so over some weird install media, using serial and all kinds of other things. If you have tunables or compile time options you want to distribute on MIPS/arm, then by all means force TCBHASH to 512. You can easily make a "small memory kernel include file" for this. Please do it. Please make ARM/MIPS/whatever better for you. As far as some pipe-dream runtime tuning, all singing/dancing thingy to make everything happy, well that doesn't exist. So either write it, or take a pragmatic approach and fix your platforms and please stop standing in the way of server OS. -Alfred On 12/7/12 3:03 PM, Adrian Chadd wrote: > Alfred, > > I can make the same argument about "out of the box" experiences with > Linux and FreeBSD on embedded. > > If the embedded experience out of the box "isn't as good or better" > than Linux, people will go with Linux. > > 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,". > > 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. > > 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. > > 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. > > 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. > > > > Adrian >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C278B0.3040107>