From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 21:47:19 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1770106566B for ; Mon, 12 Oct 2009 21:47:19 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 9214E8FC17 for ; Mon, 12 Oct 2009 21:47:19 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 7F8C6582A9; Mon, 12 Oct 2009 16:15:37 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id HL+df+VfQ+Qt; Mon, 12 Oct 2009 16:15:37 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-55-200.icecube.wisc.edu [172.16.55.200]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 4186F582A8; Mon, 12 Oct 2009 16:15:37 -0500 (CDT) Message-ID: <4AD39C78.5050309@freebsd.org> Date: Mon, 12 Oct 2009 16:15:36 -0500 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.23 (X11/20090909) MIME-Version: 1.0 To: Rafal Jaworowski References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com> <4AD32D76.3090401@freebsd.org> <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> In-Reply-To: <6C1CF2D3-A473-4A73-92CB-C45BEEABCE0E@semihalf.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Guillaume Ballet , Mark Tinguely , freebsd-arm@freebsd.org, Stanislav Sedov Subject: Re: Adding members to struct cpu_functions X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 21:47:20 -0000 Rafal Jaworowski wrote: > > On 2009-10-12, at 15:21, Nathan Whitehorn wrote: > >>>>> I was wondering whether a separate pmap module for ARMv6-7 would not >>>>> be the best approach. After all v6-7 should be considered an entirely >>>>> new architecture variation, and we would avoid the very likely >>>>> #ifdefs >>>>> hell in case of a single pmap.c. >>>>> >>>>> >>>> Yeah, I think that would be the best solution. We could conditionally >>>> select the right pmap.c file based on the target CPU selected (just >>>> like we do for board variations for at91/marvell). >>>> >>>> >>> >>> pmap.c is a very large file that seems to change very often. I fear >>> having several versions is going to be difficult to maintain. Granted, >>> I haven't read the whole file line after line. Yet it seems to me its >>> content can be abstracted to rely on arch-specific functions that >>> would be found in cpufuncs instead of hardcoded macros. Is there >>> something fundamentally wrong with enhancing struct cpufunc in order >>> to let the portmeisters decide what the MMU and caching bits should >>> look like? This is a blocking issue for me, since it looks like the >>> omap has some problem with backward compatibility mode. Without fixing >>> up the TLBs in my initarm function, it doesn't work. >>> >>> Speaking of #ifdef hell, why not breaking cpufuncs.c into several >>> cpufuncs_.c? That would be a good way to start that >>> reorganization Mark has been talking about in his email. >>> >> One thing that might be worth looking at while thinking about this is >> how this is done on PowerPC. We have run-time selectable PMAP modules >> using KOBJ to handle CPUs with different MMU designs, as well as a >> platform module scheme, again using KOBJ, to pick the appropriate >> PMAP for the board as well as determine the physical memory layout >> and such things. One of the nice things about the approach is that it >> is easy to subclass if you have a new, marginally different, design, >> and it avoids #ifdef hell as well as letting you build a GENERIC >> kernel with support for multiple MMU designs and board types (the >> last less of a concern on ARM, though). > > What always concerned me was the performance cost this imposes, and it > would be a really useful exercise to measure what is the actual impact > of KOBJ-tized pmap we have in PowerPC; with an often-called interface > like pmap it might occur the penalty is not that little.. Using the KOBJ cache means that it is only marginally more expensive than a standard function pointer call. There's a 9-year-old note in the commit log for sys/sys/kobj.h that it takes about 30% longer to call a function that does nothing via KOBJ versus a direct call on a 300 MHz P2 (a 10 ns time difference). Given that and that pmap methods do, in fact, do things besides get called and immediately return, I suspect non-KOBJ related execution time will dwarf any time loss from the indirection. I'll try to repeat the measurement in the next few days, however, since this is important to know. -Nathan