From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 21:38:15 2011 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 A6E0F1065670 for ; Mon, 7 Feb 2011 21:38:15 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64FC28FC13 for ; Mon, 7 Feb 2011 21:38:15 +0000 (UTC) Received: by iyb26 with SMTP id 26so5102269iyb.13 for ; Mon, 07 Feb 2011 13:38:14 -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=/fzeCAoLBGuSm9WzhEDLP0UBYjJJE4gEUE7nM9mya48=; b=fgw65xVIGs2moD0DFnYw8/xrwrgOoNVKWvOkHTVoKGE6dqb7GVfD+9JZfEUGu4YMub wmuEwEOxZKj8sCTFG+OWv9Vz7zC0x98c1ZYltzOA354CfYqlSWKtjdvfX1DXULMn9M70 loyLk0GeK1mT81BblibFdyKevfXqstGcGaHyg= 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=M1qXJqbQ5XhpyoAZOxAlRm7TnZ2tUHMuGYijimvGK531S04QVVFSzVcgLKaI5OFqmN 4IdIhJQzfX1muqu1IU4XcgEOPEp4m+O4ro8gxZR652iY/rdvucPZ+9LuJh/0gu8JKfMD IXuddKyS2kXC2qjepLU0oE91NINhVArzDqr2Y= Received: by 10.42.220.8 with SMTP id hw8mr5300730icb.111.1297114694367; Mon, 07 Feb 2011 13:38:14 -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 u9sm4124468ibe.20.2011.02.07.13.38.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 13:38:13 -0800 (PST) Message-ID: <4D506642.5000701@gmail.com> Date: Mon, 07 Feb 2011 15:38:10 -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> <4D5050B3.4070608@gmail.com> <4A878FC3-C011-4E40-8B36-71E36B4C4A11@mac.com> In-Reply-To: <4A878FC3-C011-4E40-8B36-71E36B4C4A11@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-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: Mon, 07 Feb 2011 21:38:15 -0000 On 2/7/2011 2:37 PM, Marcel Moolenaar wrote: > On Feb 7, 2011, at 12:06 PM, Mark Tinguely wrote: > >> On 2/7/2011 12:43 PM, 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? >>> >>> Thanks, >> It was pointed out to me that the level two cache operation were removed from the context switch on purpose, for performance reasons. I think this exception is why we still have both a level one and level two cache operation definitions. >> >> I proposed the senerio that the Sheeva cluster IO filesystem corruption problem is related to level two caches not being written back and removed upon context switch. Assuming we want to keep the performance gain by not performing the level two cache operations when we perform a context switch, and since I believe that the Sheeva has PIPT level two caches, I have a proposed fix to pmap_idcache_wdinv_range() that maps the page to a local KVA and doing the appropriate level two cache operation when needed. >> --- >> In ARMv6 and ARMv7, the inner (level one) caches are PIPT, and all these cache operations go away with the exception of the sync area of the busdma routine. > Hi Mark, > > Yes, the L2 cache on the Sheeva is PIPT, and I think it's safe to remove the > the L2 cache operations from the context switch. However, why do we have L2 > cache operations everywhere else when we only need to worry about it for DMA > and when synchronizing the I-cache in that case right? > Yes, dma sync would be the only place we need to do level-two PIPT cache operations. The new busdma routines with a "sync list" could handle this easily. The "sync list" can be made to remember which pages have an active level-lone cache mapping and and which pages did not. Obviously, the dma sync routine will perform the appropriate level-one cache operations on the pages that were marked as having active mappings and the level-two operations would be done in all cases. If I remember correctly, I played with this idea at one time, but threw it away. --Mark. I