From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751399AbaFZTCz (ORCPT ); Thu, 26 Jun 2014 15:02:55 -0400 Received: from service87.mimecast.com ([91.220.42.44]:36909 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750962AbaFZTCx convert rfc822-to-8bit (ORCPT ); Thu, 26 Jun 2014 15:02:53 -0400 Message-ID: <53AC6E78.8000706@arm.com> Date: Thu, 26 Jun 2014 20:03:20 +0100 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Russell King - ARM Linux CC: Sudeep Holla , "linux-kernel@vger.kernel.org" , Rob Herring , "linux-s390@vger.kernel.org" , Lorenzo Pieralisi , "linux-ia64@vger.kernel.org" , "linux-doc@vger.kernel.org" , Greg Kroah-Hartman , "x86@kernel.org" , Heiko Carstens , "linux390@de.ibm.com" , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH 2/9] drivers: base: support cpu cache information interface to userspace via sysfs References: <1403717444-23559-1-git-send-email-sudeep.holla@arm.com> <1403717444-23559-3-git-send-email-sudeep.holla@arm.com> <20140625222355.GK32514@n2100.arm.linux.org.uk> <53AC695C.2090406@arm.com> <20140626185005.GA32514@n2100.arm.linux.org.uk> In-Reply-To: <20140626185005.GA32514@n2100.arm.linux.org.uk> X-OriginalArrivalTime: 26 Jun 2014 19:02:50.0017 (UTC) FILETIME=[39910110:01CF9171] X-MC-Unique: 114062620025115001 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/06/14 19:50, Russell King - ARM Linux wrote: > On Thu, Jun 26, 2014 at 07:41:32PM +0100, Sudeep Holla wrote: >> Hi, >> >> On 25/06/14 23:23, Russell King - ARM Linux wrote: >>> On Wed, Jun 25, 2014 at 06:30:37PM +0100, Sudeep Holla wrote: >>>> + coherency_line_size: the minimum amount of data that gets transferred >>> >>> So, what value to do envision this taking for a CPU where the cache >>> line size is 32 bytes, but each cache line has two dirty bits which >>> allow it to only evict either the upper or lower 16 bytes depending >>> on which are dirty? >>> >> >> IIUC most of existing implementations of cacheinfo on various architectures >> are representing the cache line size as coherency_line_size, in which case I >> need fix the definition in this file. > > As an example, here's an extract from the SA110 TRM: > > StrongARM contains a 16KByte writeback data cache. The DC has 512 lines > of 32 bytes (8 words), arranged as a 32 way set associative cache, and > uses the virtual addresses generated by the processor. A line also > contains the physical address the block was fetched from and two dirty > bits. There is a dirty bit associated with both the first and second > half of the block. When a store hits in the cache the dirty bit > associated with it is set. When a block is evicted from the cache the > dirty bits are used to decide if all, half, or none of the block will > be written back to memory using the physical address stored with the > block. The DC is always reloaded a line at a time (8 words). > Thanks for the information. It's interesting that line is referred as block when referring to 2 dirty bits. I am not sure if this can be mapped to physical_line_partition = 2. Thoughts ? >> BTW will there be any architectural way of finding such configuration ? > > Not that I know of. > That's bad :) Regards, Sudeep