From owner-freebsd-arch@FreeBSD.ORG Fri Dec 7 23:32:00 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AB7A3F2 for ; Fri, 7 Dec 2012 23:32:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id D81B18FC12 for ; Fri, 7 Dec 2012 23:31:59 +0000 (UTC) Received: by mail-gg0-f182.google.com with SMTP id e5so190443ggh.13 for ; Fri, 07 Dec 2012 15:31:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=IBvJx6VLpqkCSwWKaXfzaoehWSsfi+6ZE3uxqJ1iNnU=; b=VC+gi8VbaCE/y0WfoRc7pvclyR10dzNs0IEn3Zl5grRrUXMDcmzKb1wgzAHkED5mRU n9p30gJIpWIiky7LsDo+hMcIfpGVeWDh0skK3zZYYR5mFTI1e9HDoKjO4hx4yBIeySsG tnufyL5hxdStxxt6RI+aCgR86VOINfSJ4x0YnQs0Wo4QWSmk6WXd+oh0Uj2mG+UTTTbl NbeHRA63zmbhDkL9h1xXZtWtYj/OLvEZEPb2SgHwb8v6VpUfJ7QjjPs+W6GQ2etxAGr6 Usqd0R19k7d7eJspfVJStRHHWtIOaRmcQeVEWuEgehCJI+bEJ/6OjUWKGBYOnQw/9nGF FslA== Received: by 10.236.130.106 with SMTP id j70mr10740521yhi.0.1354923118783; Fri, 07 Dec 2012 15:31:58 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id u22sm15393185yhl.2.2012.12.07.15.31.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 15:31:57 -0800 (PST) Sender: Warner Losh Subject: Re: svn commit: r243594 - head/sys/netinet Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <50C278B0.3040107@mu.org> Date: Fri, 7 Dec 2012 16:31:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52564974-563C-499F-9860-ADACA0DD22CE@bsdimp.com> References: <201211270304.qAR34PfD056691@svn.freebsd.org> <50B53ABC.1010304@freebsd.org> <50B57F46.1060207@mu.org> <50C205DC.1040701@freebsd.org> <50C23B5E.3020509@freebsd.org> <50C26BF9.1050106@mu.org> <50C278B0.3040107@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk3n2UmiaG0OfOAyxCwQkTrVPcj7Nd1XU90CKBV0Kh5giFCk6vFwqqAMRmvd7CYuuVg5RRu Cc: Adrian Chadd , Alfred Perlstein , Andre Oppermann , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 23:32:00 -0000 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"