From owner-cvs-all Sun Jul 7 15:27: 2 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6895237B400; Sun, 7 Jul 2002 15:26:54 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1172C43E31; Sun, 7 Jul 2002 15:26:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g67MQrLA017817; Sun, 7 Jul 2002 15:26:53 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g67MQqoT017816; Sun, 7 Jul 2002 15:26:52 -0700 (PDT) (envelope-from dillon) Date: Sun, 7 Jul 2002 15:26:52 -0700 (PDT) From: Matthew Dillon Message-Id: <200207072226.g67MQqoT017816@apollo.backplane.com> To: Alan Cox Cc: Peter Wemm , Jake Burkholder , Alan Cox , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/vm vm_zeroidle.c References: <20020707211530.GZ11391@cs.rice.edu> <20020707212707.BD3713808@overcee.wemm.org> <20020707213541.GA11391@cs.rice.edu> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> Thats what I did to avoid reentrancy problems. The zeroidle process uses :> CMAP3 on x86. (ugh! why not allocate some kvm? hmmm). :> :> However, with preemption, we can end up on another cpu. Or, we get :> scheduled on a different cpu next time. If we had a way to pin a khread to :> a particular cpu, now that would be nice. We could get in, pin ourselves, :> do our mappings, zero the page, unmap, unpin and done. No preemption :> problems to worry about then, and no need to worry about coherency on other :> cpus since this is explicitly single threaded. : :Let me suggest another way to deal with preemption: associate a flag :with the pmap that says flush the TLB on activation even if you :appear to be switching to the same page table, in this case the kernel's :page table. pmap_zero_page() would set and unset this flag around :the bzero(). : :Alan You mean CMAP2, not CMAP3, I think. ... *CMAP2 = PG_V | PG_RW | phys | PG_A | PG_M; invltlb_1pg((vm_offset_t)CADDR2); #if defined(I686_CPU) if (cpu_class == CPUCLASS_686) i686_pagezero(CADDR2); else #endif bzero(CADDR2, PAGE_SIZE); *CMAP2 = 0; ... Hmm. pmap_copy_page() also uses CMAP2, wouldn't they collide with each other? pmap_copy_page() and pmap_zero_page()? Am I missing something here or does it work simply because all of this stuff is still under Giant? In anycase, an obvious but unpopular answer would be to use a critical section. One page == 4K @ 200 MBytes/sec = 20 uS latency. That would work as a temporary solution. Or you could break the zeroing operation down into four 1K segments within the critical section, invltlb'ing the page between each section giving you four 5 uS critical sections. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message