From owner-freebsd-stable@FreeBSD.ORG Tue Jul 16 19:42:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 010E9117 for ; Tue, 16 Jul 2013 19:42:54 +0000 (UTC) (envelope-from e31@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1.freebsd.org (Postfix) with ESMTP id A2112D90 for ; Tue, 16 Jul 2013 19:42:54 +0000 (UTC) Received: from 3capp-gmx-bs30.server.lan ([172.19.170.82]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MaXIN-1UjaEe2LGb-00K7bd for ; Tue, 16 Jul 2013 21:42:53 +0200 Received: from [31.18.128.230] by 3capp-gmx-bs30.server.lan with HTTP; Tue Jul 16 21:42:53 CEST 2013 Message-ID: From: "Pascal Drecker" To: "Johan Hendriks" Subject: Aw: Re: status of autotuning freebsd for 9.2 Date: Tue, 16 Jul 2013 21:42:53 +0200 (CEST) Importance: normal Sensitivity: Normal In-Reply-To: References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51E1061F.3050804@ixsystems.com> <51E398F3.40008@freebsd.org> <51E3EEAA.3040106@freebsd.org> <51E3EFA8.1050606@ixsystems.com> <20130715141300.GA1986@glenbarber.us> <51E41419.3040503@ixsystems.com>, X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:QPxEB+JsFc3DRNthPaN7BVC4yodc3cCvrDgSDstHFN5 KauH/+m4KLXeOqxITcVezldR9Rqwzs/mnB4BYRqdbc8OCCZe6W 4fNDcMtpkDyfXQZzjuUs0J4iiS19Fq3u2NYrgwDLr0h10B8VJy zhiUrszWZPNQCfcUmiPJIhUiENDlxmEJRTOVNg+ZRSOw6NNniE zE9C/6Bbf5GEwuctIZDBmv5rnpHxIlSSl9RSKmbKyc0dL4K/jW TQGKi/0tFwSm/Mwypkr8mL2mqF7HOKNlpksD4lQfA8/LvXMnBJ neJW68= MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable , Alfred Perlstein X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 19:42:55 -0000 > Op maandag 15 juli 2013 schreef Alfred Perlstein (alfred@ixsystems.com) het > volgende: > >> On 7/15/13 7:13 AM, Glen Barber wrote: >>> >>> On Mon, Jul 15, 2013 at 05:48:40AM -0700, Alfred Perlstein wrote: >>> >>>> On 7/15/13 5:44 AM, Andre Oppermann wrote: >>>> >>>>> On 15.07.2013 08:38, Andre Oppermann wrote: >>>>> >>>>>> On 13.07.2013 09:47, Alfred Perlstein wrote: >>>>>> >>>>>>> Andre, we have a number of people running this patch in the >>>>>>> following configurations: >>>>>>> >>>>>>> 6-8GB ram + 10gigE ethernet using iozone over NFS. >>>>>>> >>>>>> As you haven't seen any problems yet I've asked RE to green light >>>>>> the MFC. >>>>>> >>>>> RE has rejected the MFC out of fears for unexpected regressions. >>>>> >>>>> That is unfortunate. I guess re@ doesn't understand that FreeBSD >>>> 9.2 will be unusable out of the box for doing 10gigE for more than a >>>> few microseconds. >>>> >>>> Can we not just do my original patch that has the check for 64bit >>>> pointers before unscaling maxusers? That would be dirt simple and >>>> just work with minimal risk. >>>> >>>> IMHO, this is considered a new feature, and not a critical bug fix. re@ >>> asked from the start of the code slush to avoid new features, and at >>> this point, it is too late. It is not worth introducing possible >>> regressions, which will only delay the 9.2-RELEASE. >>> >>> Glen >>> >>> OK, then we need a release notes telling people a sane value for >> nmbclusters and friends so that they know how to make 10gigE work. >> >> I'll poll my team for a value if someone else has one, that would be even >> better. >> >> -- >> Alfred Perlstein >> VP Software Engineering, iXsystems > > >Is there a possibility that a separate unofficial patch set could be >released for people who want the autotuning but do not want to run 9 >stable after 9.2 is released. >I would like the autotuning, but i am a little reluctent to use other >stable stuff i will get when tracking stable. > >Regards >Johan Hi, I think that's a good point. In our company, itīs not allowed to use the stable tree for any production system. Little and useful patches are still allowed. Having a central point with a description of each patch it would be much easier to update the release version with the needed patches. Perhaps, each patch could also have a comment section and a state (experimental, almost stable, stable ...) or a counter for successfully and unsuccessfully deployments. Any objections? Regards, Pascal