From owner-freebsd-mips@FreeBSD.ORG Sat Jun 19 17:58:33 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 09BE7106566B; Sat, 19 Jun 2010 17:58:33 +0000 (UTC) (envelope-from c.jayachandran@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 90FDD8FC1E; Sat, 19 Jun 2010 17:58:32 +0000 (UTC) Received: by gyh20 with SMTP id 20so2208858gyh.13 for ; Sat, 19 Jun 2010 10:58:31 -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=BRUcLp+8Uyjbi536eI/Ftdzx0Q8pzuLdRNAVqK50G84=; b=PKCfwuA0QAMCmjXjIFIKpaNf410m7mddW3KSFt3SX6tGpgJeIDE5+8KPkwfCv/RxWl L/DtSKhOSO4C6+qO0/syTZUmqs2ewXM/JzxlG+MNsSqx+mgqby+iNRH2mmpd24oF0ZCN O62qcq9GShrMelZnVDtVTkg6R++q/Zyw+B95g= 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=vXhkq3YzypyDEQqMCEJxHwmUTTdBSXYOZrTRo/dTTRJhl6gK44W7MOQ6ObrcCI1VO/ QUrU8VExo3KL5fvUYgfEWT1bR4fyAL77IiYX6FNMek6Td11QmFlWS1NVNtYhGNAg8D+Y yPhkku+NAF9JwXmsX+OEETrCFfHsvceGh+cVU= MIME-Version: 1.0 Received: by 10.220.47.79 with SMTP id m15mr859372vcf.233.1276970311507; Sat, 19 Jun 2010 10:58:31 -0700 (PDT) Received: by 10.220.199.200 with HTTP; Sat, 19 Jun 2010 10:58:31 -0700 (PDT) In-Reply-To: <4C1CEDFB.9070802@cs.rice.edu> 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> <4C1CEDFB.9070802@cs.rice.edu> Date: Sat, 19 Jun 2010 23:28:31 +0530 Message-ID: From: "Jayachandran C." To: Alan Cox Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 17:58:33 -0000 On Sat, Jun 19, 2010 at 9:49 PM, Alan Cox wrote: > On 6/19/2010 5:18 AM, Juli Mallett wrote: >> >> On Fri, Jun 18, 2010 at 12:41, Neel Natu =A0wrote: >> >>> >>> Hi JC, >>> >>> But what you really want here is to eliminate the intr_disable() and >>> intr_restore() and keep sched_pin() and =A0sched_unpin(). >>> >> >> Are you sure? =A0I'm not. =A0By 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. =A0This 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 =97 given that this includes routines like >> pmap_zero_page, I think there's good reason for caution. =A0Disabling >> interrupts is more conservative, but I think rightly-so. =A0I may be >> mistaken. >> > > You're not mistaken. =A0See, for example, the i386 pmap_zero_page(). =A0P= inning > by itself is insufficient because a pinned thread can be preempted, and t= he > thread that then runs (on the same processor) could call pmap_zero_page()= . > =A0So, 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. =A0However, do you want to have inter= rupts > blocked for the time it takes to read 4KB from DRAM and write 4KB to DRAM > for pmap_copy_page()? =A0Ultimately, that's the question that you need to > answer. The original implementation was to lock and sched_pin(). As Neel noted, the intr_disable was added later as a temporary fix. I think we can go back to lock and pin. If there are no objections, I will post a patch for this. Thanks, JC.