From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 1365E67B96 for ; Thu, 17 Aug 2006 10:26:41 +1000 (EST) Subject: Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT From: Benjamin Herrenschmidt To: john stultz In-Reply-To: <1155772859.15360.12.camel@localhost.localdomain> References: <17628.4499.609213.401518@cargo.ozlabs.ibm.com> <1155318983.5337.2.camel@localhost.localdomain> <1155771487.11312.114.camel@localhost.localdomain> <1155772859.15360.12.camel@localhost.localdomain> Content-Type: text/plain Date: Thu, 17 Aug 2006 02:26:07 +0200 Message-Id: <1155774368.11312.135.camel@localhost.localdomain> Mime-Version: 1.0 Cc: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Paul Mackerras , mingo@elte.hu, tglx@linutronix.de List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > Hey Ben, > I appreciate your looking over my patch. You are correct, the > conversion is a bit rough and I've not yet been able to work on the > powerpc vDSO, although I'd like to get it working so any help or > suggestions would be appreciated (is there a reason the vDSO is written > in ASM?). > > If you have any other concerns w/ that patch, or the generic timekeeping > code, please let me know and I'll do what I can to address them. Well, I've been wanting to look at your stuff and possibly do the conversion for some time, provided we don't lose performances ... Our current implementation is very optimized to avoid even memory barriers in most cases and I doubt we'll be able to be as fine tuned using your generic code, thus it's a tradeoff decision that we have to do. But then, I need to look into the details before doing any final statement :) As for why the vDSO is in assembly, well... because it's kewl ? :) More seriously, because it's much more simpler that way (and it's hand optimized in a couple of places, though that would probably benefit going through a proper scheduling analysis). The vDSO code has "special" calling conventions (like the need to tweak cr.so, the non-use of the TOC, the lack of procedure descriptors, symbols are offsets to the functions, etc...) that makes it awkward to write it in C. Ben