From owner-freebsd-mips@FreeBSD.ORG Sat Jun 19 16:19:53 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59C33106566B; Sat, 19 Jun 2010 16:19:53 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 1F5378FC0C; Sat, 19 Jun 2010 16:19:52 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 8E7042C2A92; Sat, 19 Jun 2010 11:19:52 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id apyZvPoHfDVL; Sat, 19 Jun 2010 11:19:44 -0500 (CDT) Received: from [10.24.157.225] (h-67-101-114-10.snfccasy.static.covad.net [67.101.114.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 6E1422C2A81; Sat, 19 Jun 2010 11:19:44 -0500 (CDT) Message-ID: <4C1CEDFB.9070802@cs.rice.edu> Date: Sat, 19 Jun 2010 11:19:07 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Juli Mallett References: <20100617.100235.195066307596264499.imp@bsdimp.com> <4B66E1A4-E2A5-471F-9FA4-38B506797272@lakerest.net> <20100617.110504.200754750200158040.imp@bsdimp.com> <763BEBBB-B85A-44CE-BFEE-0BADEFF3C185@lakerest.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-mips@freebsd.org Subject: Re: Merging 64 bit changes to -HEAD - part 2 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: Sat, 19 Jun 2010 16:19:53 -0000 On 6/19/2010 5:18 AM, Juli Mallett wrote: > On Fri, Jun 18, 2010 at 12:41, Neel Natu wrote: > >> Hi JC, >> >> But what you really want here is to eliminate the intr_disable() and >> intr_restore() and keep sched_pin() and sched_unpin(). >> > Are you sure? I'm not. By disabling interrupts we only have to > ensure that the fault path on any address we might access within those > routines doesn't need to use the large memory map. This isn't > trivial, but I think we can acquire a reasonable confidence about it. > If we merely pin, we have to ensure that nothing else that can run > (including interrupts and threads that run via preemption) that would > access the large memory map — given that this includes routines like > pmap_zero_page, I think there's good reason for caution. Disabling > interrupts is more conservative, but I think rightly-so. I may be > mistaken. > You're not mistaken. See, for example, the i386 pmap_zero_page(). Pinning by itself is insufficient because a pinned thread can be preempted, and the thread that then runs (on the same processor) could call pmap_zero_page(). So, pinning must be combined with a per-processor mutex. I can imagine that blocking interrupts on mips is cheaper than the combination of pinning and a mutex. However, do you want to have interrupts blocked for the time it takes to read 4KB from DRAM and write 4KB to DRAM for pmap_copy_page()? Ultimately, that's the question that you need to answer. Alan