From owner-freebsd-current Fri Feb 19 18:46:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id D1B6511B96 for ; Fri, 19 Feb 1999 18:45:04 -0800 (PST) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id TAA26560; Fri, 19 Feb 1999 19:44:54 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd026538; Fri Feb 19 19:44:52 1999 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id TAA23189; Fri, 19 Feb 1999 19:44:44 -0700 (MST) From: Terry Lambert Message-Id: <199902200244.TAA23189@usr02.primenet.com> Subject: Re: VM patch.. SMP and SO5.0 To: luoqi@watermarkgroup.com (Luoqi Chen) Date: Sat, 20 Feb 1999 02:44:44 +0000 (GMT) Cc: julian@whistle.com, current@FreeBSD.ORG, doconnor@gsoft.com.au In-Reply-To: <199902171242.HAA27848@lor.watermarkgroup.com> from "Luoqi Chen" at Feb 17, 99 07:42:26 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > It looks to me that this is serious stuff.... > > spliting the pmap out of the vmspace structure is a big change. > > caertainly a logical move but requires checking.. > > > > I guess it should be refered to the VM cabal. > > > > I presume that this is to be done in conjunction with the linuxthreads > > (and native threads) code already committed... > > > > What exactly is the reason for separating them? > > First, pmap is not split out of vmspace structure, it's just a trick to keep > struct kinfo_proc constant size (i.e. independent of NCPU), vmspace_alloc() > has been changed to allocate sizeof(struct vmspace)+sizeof(struct pmap) > amount of space and pmap lives at the bottom half. It seems to me that you could index a single extra page containing the table using the APIC ID to reference the per CPU entry (this can be obtained from the unshared common page, which has to record this for intentional IPI's, anyway) at the cost of a single dereference (6 cycles). This seems preferrable, using only 4k instead of 128k (for a 32 processor system). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message