From owner-svn-src-all@FreeBSD.ORG Thu Nov 8 07:46:28 2012 Return-Path: <owner-svn-src-all@FreeBSD.ORG> 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 048A98AF for <svn-src-all@freebsd.org>; Thu, 8 Nov 2012 07:46:28 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 66F198FC14 for <svn-src-all@freebsd.org>; Thu, 8 Nov 2012 07:46:27 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so2388078lag.13 for <svn-src-all@freebsd.org>; Wed, 07 Nov 2012 23:46:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Em99LvttzaRaWLI3dXAvuOlyn5+wDw9bth3LZ778rdk=; b=nj8thD6+1jek3ThvWxmVQErfbcuyiZSST1+ZrqYVKtB1LS6xu+JaDYubHfzkOkk4K8 5iI55qSpwsvQEyeYjXWDudbQu/CSaD3cKhwfmUXEQMjkz5N8tfgPS0a14NBhnCzUcN+Z r1O/sKl6yIlPXhS3lmA4w7qElyGY4890YSSJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Em99LvttzaRaWLI3dXAvuOlyn5+wDw9bth3LZ778rdk=; b=UhLaCo3SnolD9P5RR5n1gS9Yt2BFCSNCPGHltcLQKE6h4aGQ3B+fX1G/NxZRGVOVDg 9th6/gsFOZo7H3Z7XDpJPOQgK5VY+JSOoUPcM3kSWD5aaNWEKfamUctYsdA+tu32D5Jn tl6RKvY7ggzx7nqSA4F0kLEPxZL7QEJWgMmy9SYqKI898nimfZOmkpQsvvmAZ1klXSsp GqiqOPqWNQU0+xQk4kmfPiy0ltGb+Kg5iI/9wZeTiDPP7+zHoBLS/3vjJ7qOAni5FKtS wCG6azWaaMCbVKZKwqwZSArVTgMspO0EmqJbsec7yrzcXN60UbOuMM7QnKV5rfnD6a2m pzZg== MIME-Version: 1.0 Received: by 10.112.42.134 with SMTP id o6mr2809527lbl.105.1352360786008; Wed, 07 Nov 2012 23:46:26 -0800 (PST) Received: by 10.112.100.230 with HTTP; Wed, 7 Nov 2012 23:46:25 -0800 (PST) In-Reply-To: <509B501F.5050109@mu.org> References: <201210250146.q9P1kLi8043704@svn.freebsd.org> <20121025080551.GG35915@deviant.kiev.zoral.com.ua> <201210250950.57161.jhb@freebsd.org> <509B501F.5050109@mu.org> Date: Wed, 7 Nov 2012 23:46:25 -0800 Message-ID: <CAGE5yCobr4ZU0DEWZSez1kp4jo_V4gSby0kGqFF06Dev_Cc_jA@mail.gmail.com> Subject: Re: svn commit: r242029 - head/sys/kern From: Peter Wemm <peter@wemm.org> To: Alfred Perlstein <bright@mu.org> Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnQ4prIsRDJ5nwpZB1Uo7xNxeZNjtWHTynBsOVSzUtYsIFi1DpE9TnhiKn8n5atg5sA+Buj Cc: src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, svn-src-all@freebsd.org, Alfred Perlstein <alfred@freebsd.org>, svn-src-head@freebsd.org, Konstantin Belousov <kostikbel@gmail.com> 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" \)" <svn-src-all.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all> List-Post: <mailto:svn-src-all@freebsd.org> List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 08 Nov 2012 07:46:28 -0000 On Wed, Nov 7, 2012 at 10:24 PM, Alfred Perlstein <bright@mu.org> wrote: > [[ + peter ]] > > Folks, I spent quite a bit of time trying to figure out how to resolve > maxusers scaling in a happy way for all. > > I think I came up with a solution. > > This solution should work for i386, and other 32 bit platforms, as well as > scaling well for 64 bit (or higher) platforms that have virtually unlimited > AND 64bit with limited kernel address space. > > Here is how it works: > > We calculate the maxusers value based on physical memory, and then clamp it > down if physical memory exceeds kernel addressable memory. > > The algorithm actually remains the same for all architectures, with the > exception that machines with large kernel address space it is no longer > clamped at 384. > > I've attached a test program that lets you play with various values for > VM_MIN_KERNEL_ADDRESS, VM_MAX_KERNEL_ADDRESS and physpages. (argv[1, 2, 3] > respectively.) > > Please give me your feedback. This is still bogus. VM_MIN_KERNEL_ADDRESS and VM_MAX_KERNEL_ADDRESS have no bearing on how much space should be allocated for mbuf clusters on amd64. If anything, you want dmapbase / dmapend if you want a practical cap for amd64. Even then, jumbo clusters are >4K so they come out of kva rather than direct map. maxusers is the wrong thing for this. maxusers should, if anything, be used to set things like kern.maxproc. Preferably it should be deleted entirely and sysctl.conf should be used to change kern.maxproc. Setting limits for the mbuf / cluster pool should be a MD parameter. Trying to scale maxusers based on physical ram in order to get mbuf cluster limits set as a side effect is just plain wrong. It makes no more sense than trying to set nmbclusters based on PRINTF_BUFR_SIZE, and then trying to scale PRINTF_BUFR_SIZE in order to get desirable second and third order side effects. Scale nmbclusters based on physical ram, with a MD method for capping it for when there are MD limits (eg: disproportionately small kva on an i386 PAE machine). Don't use maxusers. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell