From owner-svn-src-all@FreeBSD.ORG Sun Nov 11 20:39:30 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B00EA289; Sun, 11 Nov 2012 20:39:30 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7EBDA8FC08; Sun, 11 Nov 2012 20:39:30 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id ABFE61A3C72; Sun, 11 Nov 2012 12:39:28 -0800 (PST) Message-ID: <50A00D00.5010901@mu.org> Date: Sun, 11 Nov 2012 12:39:28 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: svn commit: r242847 - in head/sys: i386/include kern References: <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <509E830D.5080006@mu.org> <1352568275.17290.85.camel@revolution.hippie.lan> <20121111061517.H1208@besplex.bde.org> <20121111073352.GA96046@FreeBSD.org> <509F72B0.90201@mu.org> <509FDC30.6090504@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, Alexey Dokuchaev , src-committers@freebsd.org, svn-src-all@freebsd.org, Peter Wemm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 20:39:30 -0000 On 11/11/12 12:31 PM, Adrian Chadd wrote: > On 11 November 2012 09:11, Alfred Perlstein wrote: >> Oh, OK, I didn't know it was so involved. I probably don't have anything to >> worry about then. :) > Nono - I want you to worry about it. But _I_ want there to be a > slightly longer term goal that's less about dictating policy in the > kernel and more about providing both the flexibility _and_ the > feedback so you and others can do this kind of thing in userspace > without needing to hack the kernel or recompile. > > So Alfred - are you up to the challenge? :) Enumerate _every_ thing > that maxusers tunes at startup time and make sure it's tunable at > run-time? Once that's done, we can turn maxusers into a userland > _command_ that can be run _anytime_, and you all can bikeshed over the > tuning of _that_ thing until we die from heat death. > > That way everyone wins. > > :) > > > > adrian Not really, I'm kind of stuck figuring out the following things: 1) why if_lagg doesn't get full bandwidth when in point to point mode. 2) why nfs has regressed with forced unmounts. 3) other critical performance issues wrt nfs,zfs,io. 4) ... other stuff more important. I can't devote any further effort to this maxusers thing, as I see it, I've submitted a fix that is a big step forward for all. If people want to run with this and get excited about it, I am glad. Unfortunately just because I found a light switch and turned it on, doesn't suddenly mean that I owe the community a fancy new vanity installed. After all, it is just a toilet, now that I don't have to worry about everyone pissing all over the seat, my job is done. There are more important goals. I'm not playing the "you touched it, it's your responsibility game" any longer. this is why no one has bothered to fix it, because the community feels that it is ok to saddle someone making a small incremental change with an impossibly hard halting problem of nonsense. So, yeah feel free to install that vanity, but don't make me sorry I flipped a switch. This is why we all carry flashlights around (our personal sysctl.conf), because we're afraid of this community reaction and wonder why there's piss on the seat. I think Bruce said it best: > But don't ask alfred to fix all the old mistakes. This will be my last email on this issue. -Alfred