From owner-svn-src-all@FreeBSD.ORG Wed Jun 2 12:17:02 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 104A11065675; Wed, 2 Jun 2010 12:17:02 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C11298FC17; Wed, 2 Jun 2010 12:17:01 +0000 (UTC) Received: by pwj1 with SMTP id 1so1290194pwj.13 for ; Wed, 02 Jun 2010 05:17:01 -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=WZVpKJipn/bi54y3AS8mws9k3kzcGwnQ+QzvLOute5g=; b=YoVFB34ZfLeSOUcR5H4quLvj004fdYcoK8JWMKR/du+I4Xk1mZ09VymBmZdGWG6O3C zSkcqj8Va+SApFRI7czKMLXygI5xYoXpKZgyPBHjHu5QCb1pUsZ+fXC0CKdZPzv13o0x cB1Sqx4a8tf47LtzMwqwwr4cCPnaDB34iOTRs= 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=W895eVpXcGTb6or4vb2K5rT7wI4H5Nc/uqJeC4zFGBiMe/2zG6w0awOmw28PhduV3w dYB4A+/htoOmV39wkaT3TXvpgslCP5++MljrENdAxR/v09yDvl+Hug0lTRPUIHtaoMkO 6H7rGQiVnbbqn9U5Iceu7PGRGUnEmq6wsHW78= MIME-Version: 1.0 Received: by 10.141.53.3 with SMTP id f3mr6280935rvk.195.1275481021282; Wed, 02 Jun 2010 05:17:01 -0700 (PDT) Received: by 10.141.4.3 with HTTP; Wed, 2 Jun 2010 05:17:01 -0700 (PDT) In-Reply-To: <4C05F9BC.40409@cs.rice.edu> References: <201005271005.o4RA5eVu032269@svn.freebsd.org> <4C058145.3000707@cs.rice.edu> <4C05F9BC.40409@cs.rice.edu> Date: Wed, 2 Jun 2010 17:47:01 +0530 Message-ID: From: "C. Jayachandran" To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Jayachandran C." , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Randall Stewart Subject: Re: svn commit: r208589 - head/sys/mips/mips X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 12:17:02 -0000 On Wed, Jun 2, 2010 at 11:57 AM, Alan Cox wrote: > C. Jayachandran wrote: >> >> On Wed, Jun 2, 2010 at 3:23 AM, Alan Cox wrote: >> >>> >>> On 5/27/2010 5:05 AM, Jayachandran C. wrote: >>> >>>> >>>> Author: jchandra >>>> Date: Thu May 27 10:05:40 2010 >>>> New Revision: 208589 >>>> URL: http://svn.freebsd.org/changeset/base/208589 >>>> >>>> Log: >>>> =A0Call VM_WAIT in pmap_ptpgzone_allocf() if =A0M_WAITOK is set. >>>> =A0Removed unused variable. >>>> >>>> =A0Approved by: rrs (mentor) >>>> >>>> >>>> >>> >>> I'm afraid that this will work some of the time, but not all of the tim= e. >>> =A0Specifically, there is no guarantee that any of the available free (= or >>> cached) pages after the VM_WAIT will fall within the range of suitable >>> physical addresses. =A0Moreover, and perhaps most worrisome, is that th= is >>> function could do a lot of spinning. =A0Every time this function sleeps= and >>> a >>> single page is freed (or cached) by someone else, this function will be >>> reawakened. =A0With a little bad luck, you could spin indefinitely. >>> >>> For essentially this reason, contigmalloc(), kmem_alloc_contig(), and >>> kmem_alloc_attr() don't use VM_WAIT, but instead a function called >>> vm_contig_grow_cache(). >>> >> >> I had seen the vm_contig_grow_cache() usage, but could not use it as >> it was defined as a static function. >> >> I did not want to use contigmalloc()/kmem_alloc_contig() either, >> because the pages in that memory region are already direct mapped and >> setting up another mapping is not necessary. The overall idea is to >> allocate pages in the direct mapped region for the page table entries >> so that we don't take a TLB exception while accessing page tables >> (which is costly as MIPS has a software TLB exception handler). >> >> Can you suggest the right way to do this? I will make the changes and >> send a patch for approval. >> > > I would encourage you to make vm_contig_grow_cache() an extern function a= nd > use it. =A0(vm/vm_pageout.h is probably the best place for the function > prototype.) I'll create a patch for this and related changes in mips/mips/pmap.c > If you're interested in taking this a small step further, it would make > sense to add two parameters to vm_contig_grow_cache() and > vm_contig_launder(): a "low" and a "high" physical address. > =A0vm_contig_launder() could then skip pages that are outside the desired > range. I am looking at this now, part of the logic which vm_phys_alloc_contig() uses to check pages address should work here. Will send out changes for this, if it works out. Thanks, JC.