From owner-svn-src-head@FreeBSD.ORG Sun Nov 11 05:55:19 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAAE9DD9 for ; Sun, 11 Nov 2012 05:55:19 +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 425308FC15 for ; Sun, 11 Nov 2012 05:55:18 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so4910775lag.13 for ; Sat, 10 Nov 2012 21:55:17 -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=edDcg5PWSV6IbotOys6Mk+XRK26rSSdoMwWckqZeIJM=; b=G2grn7u9DIZThOJ4lHyuj6hD15eDAxR3+eUIMfpUhfUA530ZHiSOfnmna7XU0CWIC6 w6q7++xTqK+pnUQxj8dkVvMFKw0Z2WxHYteXCijpHHsqXLtIzPRhllIuMlorpx9mqzG6 978CXBKxIxMSk3nQ3XHUPFWqtd6YV0LjeqWuo= 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=edDcg5PWSV6IbotOys6Mk+XRK26rSSdoMwWckqZeIJM=; b=gkbDlepIuHnRtw2kXyH79LlAEnFJXZ0fLRmLQuQS4MSWqkVb54kdJWA0RydEfi3CTF jQH5DluH09t7HdB9Qu8NOq/beXIuP3zu6Qc6oJlWMu6K50iI6ujffm8E8bpSGVrmnabr wLWfwAw7YhGmZPrymRAZe2uZbXZRWgbk9k7eHGw6rNt2pO6PZDRuA/OIbhdMCEjMqKs1 4Moh4ro2s40jERkS3Ntjj7B+ECAAdFmOPDkVtd4ucY/l/oMh28Qc1f9hshnm2Tue78HI +SHqIaKcMHW7BFQdm6wmx8bRVNvMdXyUOBKJ8SYaUKs11qe9YDus4v7vmQJulAfI1NZx Ma3Q== MIME-Version: 1.0 Received: by 10.112.39.105 with SMTP id o9mr2802721lbk.123.1352613317777; Sat, 10 Nov 2012 21:55:17 -0800 (PST) Received: by 10.112.100.230 with HTTP; Sat, 10 Nov 2012 21:55:17 -0800 (PST) In-Reply-To: <509EA869.6030407@freebsd.org> References: <201211100208.qAA28e0v004842@svn.freebsd.org> <509DC25E.5030306@mu.org> <509E3162.5020702@FreeBSD.org> <509E7E7C.9000104@mu.org> <509E830D.5080006@mu.org> <509E847E.30509@mu.org> <509E8930.50800@mu.org> <509EA869.6030407@freebsd.org> Date: Sat, 10 Nov 2012 21:55:17 -0800 Message-ID: Subject: Re: svn commit: r242847 - in head/sys: i386/include kern From: Peter Wemm To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlT/vNg4guPTHFd+7DIM88V+VDK+SFzopaq2rah69pzvYPBmeAgmEGFZv5N4inP/GMjmNom Cc: src-committers@freebsd.org, Eitan Adler , Alfred Perlstein , svn-src-all@freebsd.org, Alfred Perlstein , svn-src-head@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 05:55:19 -0000 On Sat, Nov 10, 2012 at 11:18 AM, Andre Oppermann wrote: > On 10.11.2012 19:04, Peter Wemm wrote: >> >> On Sat, Nov 10, 2012 at 9:48 AM, Eitan Adler wrote: >>> >>> On 10 November 2012 12:45, Peter Wemm wrote: >>>> >>>> On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote: >>>>> >>>>> On 10 November 2012 12:04, Alfred Perlstein wrote: >>>>>> >>>>>> Sure, if you'd like you can help me craft that comment now? >>>>> >>>>> >>>>> I think this is short and clear: >>>>> === >>>>> Limit the amount of kernel address space used to a fixed cap. >>>>> 384 is an arbitrarily chosen value that leaves 270 MB of KVA available >>>>> of the 2 MB total. On systems with large amount of memory reduce the >>>>> the slope of the function in order to avoiding exhausting KVA. >>>>> === >>>> >>>> >>>> That's actually completely 100% incorrect... >>> >>> >>> okay. I'm going by the log messages posted so far. I have no idea how >>> this works. Can you explain it better? >> >> >> That's exactly my point.. >> >> You get 1 maxuser per 2MB of physical ram. >> If you get more than 384 maxusers (ie: 192GB of ram) we scale it >> differently for the part past 192GB. I have no idea how the hell to > > > Rather past 768MB of RAM. You're right. It is 768M ram before the slope of the cap changes. maxusers = physpages / (2 * 1024 * 1024 / PAGE_SIZE); This is simple math. physpages is units of pages. (2 * 1024 * 1024 / PAGE_SIZE) = 2MB, converted to pages. So maxusers = 1 per 2MB of physical ram. 20MB of ram calculates maxusers = 10. 768M ram gives maxusers = 384. Above 768M, one maxuser is allocated per 2 * 8 = 16MB of ram. 4G gives maxusers = 592. 16G gives maxusers = 1360. >> calculate that. >> You get an unlimited number of regular mbufs. >> You get 64 clusters per maxuser (128k) >> Unless I fubared the numbers, this currently works out to be 6%, or 1/16. >> >> Each MD backend gets to provide a cap for maxusers, which is in units >> of 2MB. For an i386 PAE machine you have a finite amount of KVA space >> (1GB, but this is adjustable.. you can easily configure it for 3GB kva >> with one compile option for the kernel). The backends where the >> nmbclusters comes out of KVA should calculate the number of 2MB units >> to avoid running out of KVA. >> >> amd64 does a mixture of direct map and kva allocations. eg: mbufs and >> clusters come from direct map, the jumbo clusters come from kva. I'm aware of this. Behavior of how to set a "Don't die" exhaustion is MD. -- 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