From owner-freebsd-mips@FreeBSD.ORG Wed Jun 9 05:50:24 2010 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6422106564A; Wed, 9 Jun 2010 05:50:24 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 630388FC24; Wed, 9 Jun 2010 05:50:24 +0000 (UTC) Received: by vws1 with SMTP id 1so575901vws.13 for ; Tue, 08 Jun 2010 22:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j+QBLzLRA94V0clIBAlWct1sAH2Ew1WLJ3InQkAXMqQ=; b=Sd4YCfufszrYQ8k1Dzp9nVLGF3uR5m7D/xL/PlOCHZg8sdb6HNsdj0MwTZa/bPJDTj A4yLeNFwhum+dBN/TG2t4EtFlCdU6B8ylkaZn+Hw8wje7k1X5YtOwYmBS1RZ3O9IeRNG dzhGFl1k3nM1rCnOVR0UXiIRW+Q5JxU2JfTGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wR4r291+XOiHdS3Qgvjp6+Xq7Fq1E1jq0Spx2zY45c6yTAjHh7sdPXccSFCZPFfTLP s5RvZ5d7k/51cQIgVG7FxfsWHrNNhDkGEMuIhT0WHhhiqmEwPl7WLqzqTCdJoaFIGP5S lDWaAcJl6d1gPeevi/DMctbvS5hf/vJQqz6bQ= MIME-Version: 1.0 Received: by 10.224.27.142 with SMTP id i14mr1436526qac.272.1276062622667; Tue, 08 Jun 2010 22:50:22 -0700 (PDT) Received: by 10.220.189.13 with HTTP; Tue, 8 Jun 2010 22:50:22 -0700 (PDT) In-Reply-To: References: <4C07E07B.9060802@cs.rice.edu> <4C09345F.9040300@cs.rice.edu> <4C0D2BEA.6060103@cs.rice.edu> <4C0D3F40.2070101@cs.rice.edu> <20100607202844.GU83316@deviant.kiev.zoral.com.ua> <4C0D64B7.7060604@cs.rice.edu> <4C0DE424.9080601@cs.rice.edu> Date: Wed, 9 Jun 2010 11:20:22 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , "Jayachandran C." , mips@freebsd.org Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 05:50:25 -0000 On Wed, Jun 9, 2010 at 3:01 AM, Jayachandran C. wrote: > On Tue, Jun 8, 2010 at 12:03 PM, Alan Cox wrote: >> >> VM_FREEPOOL_DIRECT is used by at least amd64 and ia64 for page table pag= es >> and small kernel memory allocations. =A0Unlike mips, these machines don'= t have >> MMU support for a direct map. =A0Their direct maps are just a range of >> mappings in the regular (kernel) page table. =A0So, unlike mips, accesse= s >> through their direct map may still miss in the TLB and require a page ta= ble >> walk. =A0VM_FREEPOOL_* is a way to increase the physical locality (or >> clustering) of page allocations, so that, for example, page table page >> accesses by the pmap on amd64 are less likely to miss in the TLB. =A0How= ever, >> it doesn't place a hard restriction on the range of physical addresses t= hat >> will be used, which you need for mips. >> >> The impact of this clustering can be significant. =A0For example, on amd= 64 we >> use 2MB page mappings to implement the direct map. =A0However, old Opter= ons >> only had 8 data TLB entries for 2MB page mappings. =A0For a uniprocessor >> kernel running on such an Opteron, I measured an 18% reduction in system >> time during a buildworld with the introduction of VM_FREEPOOL_DIRECT. = =A0(See >> the commit logs for vm/vm_phys.c and the comment that precedes the >> VM_NFREEORDER definition on amd64.) >> >> Until such time as superpage support is ported to mips from the amd64/i3= 86 >> pmaps, I don't think there is a point in having more than one VM_FREEPOO= L_* >> on mips. =A0And then, the point would be to reduce fragmentation of the >> physical memory that could be caused by small allocations, such as page >> table pages. > > Thanks for the detailed explanation. > > Also, after looking at the code again, =A0I think vm_phys_alloc_contig() > can optimized not to look into segments which lie outside the area of > interest. The patch is: [...] > This change, along with the vmparam.h changes for HIGHMEM, I think we > should be able to use =A0vm_phys_alloc_contig() for page table pages (or > have I again missed something fundamental?). That patch was obviously wrong - many segments can map to a freelist as the comment right above my change noted. But the idea of eliminating freelists for which all the segments are outside (low,high) may still be useful, will look at this some more. JC.