From owner-freebsd-stable@FreeBSD.ORG Mon Jul 8 14:41:47 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B785DE4F; Mon, 8 Jul 2013 14:41:47 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by mx1.freebsd.org (Postfix) with ESMTP id 6CB21164C; Mon, 8 Jul 2013 14:41:47 +0000 (UTC) Received: by mail-ob0-f179.google.com with SMTP id xk17so5596385obc.10 for ; Mon, 08 Jul 2013 07:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CVGhfwTglARovU86hlMZOKKYbI3+qi1ZmUmddkn+oa0=; b=Rt9B7Fb6hB1qZmHEow6SEE90XFvZWzyERttVK9arLpkdSo4Cwx1gZUhnxfUOwrkVtE YdrFElc9QGPlxpvaCJVdYLn0eliupXsswblgGYW5nI1pDXxxnH5KOYnGW9Nsi7EjBxwM r37ZK9iuDHC0hFxfXMZ1nG3FDBVbJyKT8aX7t+e8Xm7h5GfHMdDuH4wfWmoT3jusXGKZ p8u75aaJjJkdPUUHmPcIJCiG0AtsQVwn067bpbzfD7+889bW3micPE4bynTHu8A2GuY8 L21DiBhe+tEbJr2Kjb58dtS/Dreo0tZ5Zj7n4lHSKS9RhIGzWdlR3rGM1j5tiv54er5T FCdw== MIME-Version: 1.0 X-Received: by 10.60.146.134 with SMTP id tc6mr20229325oeb.95.1373294506987; Mon, 08 Jul 2013 07:41:46 -0700 (PDT) Received: by 10.76.90.197 with HTTP; Mon, 8 Jul 2013 07:41:46 -0700 (PDT) In-Reply-To: <51DACE93.9050608@freebsd.org> References: <51D90B9B.9080209@ixsystems.com> <51D92826.1070707@freebsd.org> <51D9B24B.8070303@ixsystems.com> <51DACE93.9050608@freebsd.org> Date: Mon, 8 Jul 2013 10:41:46 -0400 Message-ID: Subject: Re: status of autotuning freebsd for 9.2 From: Outback Dingo To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org, re@freebsd.org, nonesuch@longcount.org, 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: Mon, 08 Jul 2013 14:41:47 -0000 On Mon, Jul 8, 2013 at 10:37 AM, Andre Oppermann wrote: > On 07.07.2013 20:24, Alfred Perlstein wrote: > >> On 7/7/13 1:34 AM, Andre Oppermann wrote: >> >>> Can you help me with with testing? >>> >>> Yes. Please give me your proposed changes and I'll stand up a machine >> and give feedback. >> > > http://people.freebsd.org/~**andre/mfc-autotuning-20130708.**diff > > This is functional bundle MFC of these original commits: > > MFC r242029 (alfred): > > Allow autotune maxusers > 384 on 64 bit machines. > > MFC r242847 (alfred): > > Allow maxusers to scale on machines with large address space. > > MFC r243631 (andre): > > Base the mbuf related limits on the available physical memory or > kernel memory, whichever is lower. The overall mbuf related memory > limit must be set so that mbufs (and clusters of various sizes) > can't exhaust physical RAM or KVM. > > At the same time divorce maxfiles from maxusers and set maxfiles to > physpages / 8 with a floor based on maxusers. This way busy servers > can make use of the significantly increased mbuf limits with a much > larger number of open sockets. > > MFC r243639 (andre): > > Complete r243631 by applying the remainder of kern_mbuf.c that got > lost while merging into the commit tree. > > MFC r243668 (andre): > > Using a long is the wrong type to represent the realmem and maxmbufmem > variable as they may overflow on i386/PAE and i386 with > 2GB RAM. > > MFC r243995, r243996, r243997 (pjd): > > Style cleanups, Make use of the fact that uma_zone_set_max(9) already > returns actual limit set. > > MFC r244080 (andre): > > Prevent long type overflow of realmem calculation on ILP32 by forcing > calculation to be in quad_t space. Fix style issue with second parameter > to qmin(). > > MFC r245469 (alfred): > > Do not autotune ncallout to be greater than 18508. > > MFC r245575 (andre): > > Move the mbuf memory limit calculations from init_param2() to > tunable_mbinit() where it is next to where it is used later. > > MFC r246207 (andre): > > Remove unused VM_MAX_AUTOTUNE_NMBCLUSTERS define. > > MFC r249843 (andre): > > Base the calculation of maxmbufmem in part on kmem_map size > instead of kernel_map size to prevent kernel memory exhaustion > by mbufs and a subsequent panic on physical page allocation > failure. > > > would it be safe to throw a couple of high end storage systems into this testing pool ?? each has 128G Memory, and dual quad core procs, with 10GB Intel interfaces all they are design to do it samba and nfs and ive been fighting performance with samba and nfs on these systems, Id be curious if autotuning might help, to be honest, theres so much to tweak for samba, nfs, zfs alone in different formats, im surprised anyone has it running efficiently. > -- > Andre > > > ______________________________**_________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-**stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@**freebsd.org > " >