From owner-freebsd-smp Wed Aug 22 23:19:26 2001 Delivered-To: freebsd-smp@freebsd.org Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by hub.freebsd.org (Postfix) with ESMTP id 35C0B37B40C; Wed, 22 Aug 2001 23:19:20 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.245.134.55.Dial1.SanJose1.Level3.net [209.245.134.55]) by snipe.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f7N6JFQ22355; Wed, 22 Aug 2001 23:19:16 -0700 (PDT) Message-ID: <3B84A08D.92864A27@mindspring.com> Date: Wed, 22 Aug 2001 23:19:57 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Dillon Cc: Jake Burkholder , John Baldwin , freebsd-smp@FreeBSD.ORG, freebsd-alpha@FreeBSD.ORG Subject: Re: Preliminary proposed rollup of kernel submap initialization code References: <200108210157.f7L1vAh10384@k7.locore.ca> <200108211736.f7LHaoC64628@earth.backplane.com> <3B83623D.9DC45B93@mindspring.com> <200108221456.f7MEufD74609@earth.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 Matt Dillon wrote: > 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? I was just thinking that, wherever possible, the reference should supply easy to understand C code that can be replaced by platform specific assembly versions, when necessary. The issue with the pointer pass is that it'll be a bit harder to code an assembly version on some platforms. I doubt we'll ever run on IBM big iron, where pointer arithmatic is nearly impossible, but you never know... > kmi is static in the MD sections because it allows the kernel to compile > for all platforms without us having to 'fix' all platforms all at once. > 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. Uh, I complained that the declaration was _NOT_ static... that's what made the pointer reference to it so curious: it was already available as a global, so it didn't make sense why you were passing its address around, and then doing pointer math on it, instead of just referencing the elements directly. The use of descriptors in OpenSSL, particularly in the hardware acceleration code, and in the VFS (this latter could be made much simpler by sorting the VOP elements by descriptor order, and then using a direct dereference) are more expensive by far than a direct reference would be... if one were available. You can actually eliminate about 500 cycles out of the interface calls in OpenSSL by referencing the auto descriptor structure elements directly, instead of using the pointer to the descriptor substructure, to fill out the subcall specific descriptor fields, FWIW. Again, I don't expect this code to be used as often as the OpenSSL code is used (but the OpenSSL code could certainly stand fixing), but as a reference implementation it makes sense to keep it as simple as possible, while still getting the job done. Regards, -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message