From owner-freebsd-arch@FreeBSD.ORG Mon Jul 26 19:18:50 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A221810656B0; Mon, 26 Jul 2010 19:18:50 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1888FC12; Mon, 26 Jul 2010 19:18:50 +0000 (UTC) Received: by pvh1 with SMTP id 1so247366pvh.13 for ; Mon, 26 Jul 2010 12:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=C5M8sh625HpmpNqugV+mGGDAeJhwtqJNCxz4LQrvlPk=; b=mPzahy4rIGS5KDKELPcTU38OC4RXiw1+4yBy1ru3zUcR5K4w4Cxyy7QFa+nsWisvv4 IEM8VVm4uqDq5DC7rDUcwTcr6NiF1Ws5XPxZgNqlRS1tr7ZlZWtvCS8a9xbn4OY6aI5s 6P/y98qRbUN3WQRfUHvzkijbI13ZYKLvvEyGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=VW1cDfsL6cetH9oQsMxcmKny43CkK6cqDzcDya397OFshmZY/EGOFreQiVFtT97BTm 6/UjgyUqeWgt4smWrlKH6dT8NKHP4NlhGMDYn8jQqaVLWlvtq6F09DWqb3gmu3xPBr9g cAwGtU3xoH5HJBhp0WTXIAWuoMJQD+hDHH9Xk= MIME-Version: 1.0 Received: by 10.142.223.12 with SMTP id v12mr9388422wfg.76.1280170129445; Mon, 26 Jul 2010 11:48:49 -0700 (PDT) Received: by 10.229.239.5 with HTTP; Mon, 26 Jul 2010 11:48:48 -0700 (PDT) In-Reply-To: References: <4C4DB2B8.9080404@freebsd.org> Date: Mon, 26 Jul 2010 13:48:48 -0500 Message-ID: From: Alan Cox To: Matthew Fleming Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Andriy Gapon , freebsd-arch@freebsd.org Subject: Re: amd64: change VM_KMEM_SIZE_SCALE to 1? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 19:18:50 -0000 On Mon, Jul 26, 2010 at 12:04 PM, Matthew Fleming wrote: > On Mon, Jul 26, 2010 at 9:07 AM, Andriy Gapon wrote: > > > > Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set > to 1? > > I mean things potentially breaking, or some unpleasant surprise for an > > administrator/user... > > As I understand it, it's merely a resource usage issue. amd64 needs > page table entries for the expected virtual address space, so allowing > more than e.g. 1/3 of physical memory means needing more PTEs. But > the memory overhead isn't all that large IIRC: each 4k physical memory > devoted to PTEs maps 512 4k virtual addresses, or 2MB, so e.g. it > takes about 4MB reserved as PTE pages to map 2GB of kernel virtual > address space. > > Having cut my OS teeth on AIX/PowerPC where virutal address space is > free and has no relation to the size of the hardware page table, the > FreeBSD architecture limiting the size of the kernel virtual space > seemed weird to me. However, since FreeBSD also does not page kernel > data to disk, there's a good reason to limit the size of the kernel's > virtual space, since that also limits the kernel's physical space. > > This last answer is the answer that I would give as well. As you say, the page table memory isn't that significant. > In other words, setting it to 1 could lead to the system being out of > memory but not trying to fail kernel malloc requests. I'm not > entirely sure this is a new problem since one could also chew through > physical memory with sub-page uma allocations as well on amd64. > > Yes, on both counts. However, many of the things that we might allocate with uma_small_alloc() have caps, e.g., vnode structures, mitigating the risk somewhat. Alan