svn commit: r243594 - head/sys/netinet

[Warner Losh]

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.
> 
> 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.

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
> 
> 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
>> 
> 
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"