From owner-freebsd-arm@FreeBSD.ORG Wed Feb 9 17:59:11 2011 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CAE91065679 for ; Wed, 9 Feb 2011 17:59:11 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9558FC14 for ; Wed, 9 Feb 2011 17:59:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so387961iwn.13 for ; Wed, 09 Feb 2011 09:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mu6n5o7u9gkhds0/CWBIvr1DG+SNCGOPMkYMMHwi0SY=; b=KsR5Se7qtbHYYEzsDCUO/optXVKlv+xeII2bBujProkYAR1YA2oO3QN5fBEl2ifcrX v9moHgqkg11QKIfaqmwGCoo5k59Na2PnGk1ZiwU/mXNuhYfyyavV04BO5tfYdXy1avb7 GTnRVEo89NtHmsdsG+2d6wMutK8fOTPZtzQ/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VZR/p7S1QvUnsBSCTBZbw4gqCtJhAagHxI6HthIu9SisiMCwwkGK9OJtBHvOrJLfbY BlZzTKMa290JWahgz/ebmJNInRrzJMjHLkhwiluDpDcwj/+oHRfty4Id7TIDylu9YmBS V+TceN4WKAJudJo15TnY/EIDhl8W1dC7vJ2EE= Received: by 10.42.223.197 with SMTP id il5mr12374758icb.48.1297272867697; Wed, 09 Feb 2011 09:34:27 -0800 (PST) Received: from [192.168.1.101] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id i2sm379996icv.15.2011.02.09.09.34.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 09:34:25 -0800 (PST) Message-ID: <4D52D01D.7060204@gmail.com> Date: Wed, 09 Feb 2011 11:34:21 -0600 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marcel Moolenaar References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> <20110209095630.GA57320@ci0.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org Subject: Re: Elimination of cpu_l2cache_* 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: Wed, 09 Feb 2011 17:59:11 -0000 On 2/9/2011 10:25 AM, Marcel Moolenaar wrote: > On Feb 9, 2011, at 1:56 AM, Olivier Houchard wrote: > >> Hi Marcel, >> >> On Mon, Feb 07, 2011 at 10:43:54AM -0800, Marcel Moolenaar wrote: >>> All, >>> >>> I've been reviewing the use of the cpu_l2cache_* functions and found >>> that 1) they're missing from cpu_witch() and 2) they are always used >>> in conjunction with either cpu_idcache_* or cpu_dcache_*. >>> >>> Since most CPU variants define them as null ops, isn't it better to >>> incorporate the functionality of cpu_l2cache_* in cpu_idcache_* and >>> cpu_dcache_* and eliminate them altogether? >>> >>> Any objections to me removing cpu_l2cache_* and therefore changing >>> the semantics of cpu_idcache_* and cpu_dcahce_* to apply to all >>> relevant cache levels? > Hi Olivier, good to hear from you, > >> I chose to make the l2cache functions separate from the [i]dcache functions >> because there's a number of cases where L1 cache flush was needed, but not L2, >> and that would be a performance penalty to do both. > I'll take it from this that the L2 is PIPT for the Xscale core 3 > as well, right? > >> Also, more CPU variants define them as null ops now, but most new arm cpus >> come with a L2 cache,, so we need to think about it carefully. > Agreed. If the L2 cache is PIPT, then we should not do tie L1& L2 > together and I'd like to change the code to remove the L2 cache > operations from most places where we have them now. My point is the L2 caches better be PIPT. If the L2 cache are virtual indexed and we do not flush them on context change, then we could have multiple copies in the L2 cache when we share a page and the width of the level 2 cache is larger than a page. It only make sense from the hardware design side to make the L2 cache PIPT. > What I'm thinking about is the following: introduce pmap_switch(), > as we have it on ia64. This function is called from cpu_switch to > replace the existing active pmap with a new one. In pmap_switch() > we flush the VIVT caches *IFF* the new pmap is different from the > old (=currently active) pmap. Consequently, we're not going to > flush the VIVT caches when we switch between kernel threads, nor > do we flush the caches when we switch between threads in the > same process. In all other cases we'll flush the VIVT caches. > > pmap_switch() is also called when a pmap interface function gets > a pmap to work on. The interface function switches the pmap, (if > applicable) which may or may not force a VIVT cache operation. > The pmap interface function does it's work, after which it switches > back to the pmap that was active on entry to the function. This > then could also trigger VIVT cache operations. > > In any case: I'm thinking that this removes most of the explicit > calls to the cache functions while still guaranteing coherency. > > I need to look into the aliasing case to see how that is handled. > I have some ideas for that too... > > Thoughts? > There are places we can remove redundant cache operations; pmap_qenter() comes to mind. A lot of the cache operations outside of a context switch occur because we share a page within the same memory map (I think that is what you mean by the aliasing case), we turn access or writing off, and for dma. For VIVT caches, I can't see these operations going away. The page copying and zeroing are other examples and it seems like they need cache operations. --Mark.