From owner-freebsd-smp Wed Aug 22 12:24:23 2001 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 837EE37B43B; Wed, 22 Aug 2001 12:23:49 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id FAA19268; Thu, 23 Aug 2001 05:23:36 +1000 Date: Thu, 23 Aug 2001 05:23:30 +1000 (EST) From: Bruce Evans X-X-Sender: To: Matt Dillon Cc: Terry Lambert , Jake Burkholder , John Baldwin , , Subject: Re: Preliminary proposed rollup of kernel submap initialization code In-Reply-To: <200108221456.f7MEufD74609@earth.backplane.com> Message-ID: <20010823051540.U15063-100000@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 22 Aug 2001, Matt Dillon wrote: > :Then you pass it's address in... > : > :> +void > :> +vm_ksubmap_init(struct kva_md_info *kmi) > :> +{ > : > :And then use much more expensive pointer arithmatic... > : > :> + buffer_map = kmem_suballoc(clean_map, &kmi->buffer_sva, > :> + &kmi->buffer_eva, (nbuf*BKVASIZE)); > : > :I understand that this is called once, but doesn't this > :really obfuscate things? > : > :-- Terry > > I don't follow. The argument passing and pointer arithmatic is not > expensive at all - in fact, it is less expensive then the original MD > code if you look at the assembly output! And who really gives a damn > about a few nanoseconds during boot anyway? > > kmi is static in the MD sections because it allows the kernel to compile global > for all platforms without us having to 'fix' all platforms all at once. Make it global in an MI section and it automatically implements it in all platforms at once (platforms that haven't been "fixed" simply don't use it). > One could also argue that the mainline kernel code has no direct need to > know about the contents of kmi but that wasn't the main reason for doing > it that way. I prefer keeping the variables separate like they used to be. There is even less need for them to be combined in a struct than there used to be, since centralizing the their initializations ensures that they are the same for all arches. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message