From owner-freebsd-arm@FreeBSD.ORG Mon Feb 7 20:06:29 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 4D941106564A for ; Mon, 7 Feb 2011 20:06:29 +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 114F38FC19 for ; Mon, 7 Feb 2011 20:06:28 +0000 (UTC) Received: by iwn39 with SMTP id 39so5013085iwn.13 for ; Mon, 07 Feb 2011 12:06:28 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3ERj5q4OhZVMy5vmBsElr5IjX8t2TGFvfC0UVk2hTwU=; b=wDc5EoCJapGB4hsh1Fr0mOOKaS5zhgT8abTvHeDb+o67yfqmr0rD0w1zXiwmYp1/qA j6773c2MGnHGKqNbITEUnMRSsywRmeyggka0o34QZg3PEvLRLoUXf/0lj+nDBJBfsjYt cTaZsFV7lSDgL0aBNxnG7DNYh0lsQ94AXnSk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=F0y8O4DWDAN975135lrHSZlMbF9PZSpbH5L7UsfTc8jTMVZG6/NxpT4YU6cvzKzqB7 dzZnlYCT4WGKNb7x9Cc0XTy/Rp9oPSSbMNj3zWK/pJIUNCxsR6JPIZ6efmcBowEJRNXc wp9nU424AjDEhY5a+xp8UcDFbjE+7SQztgG3E= Received: by 10.42.174.71 with SMTP id u7mr5794420icz.62.1297109188501; Mon, 07 Feb 2011 12:06:28 -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 c4sm3653492ict.19.2011.02.07.12.06.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 12:06:17 -0800 (PST) Message-ID: <4D5050B3.4070608@gmail.com> Date: Mon, 07 Feb 2011 14:06:11 -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: freebsd-arm@freebsd.org References: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> In-Reply-To: <857AA8D9-5C41-4D80-A3B5-0D29BE051014@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 20:06:29 -0000 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. --Mark Tinguely