Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751290AbaFZSuR (ORCPT ); Thu, 26 Jun 2014 14:50:17 -0400 Received: from gw-1.arm.linux.org.uk ([78.32.30.217]:44316 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750944AbaFZSuP (ORCPT ); Thu, 26 Jun 2014 14:50:15 -0400 Date: Thu, 26 Jun 2014 19:50:05 +0100 From: Russell King - ARM Linux To: Sudeep Holla Cc: "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 Message-ID: <20140626185005.GA32514@n2100.arm.linux.org.uk> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53AC695C.2090406@arm.com> User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). > BTW will there be any architectural way of finding such configuration ? Not that I know of. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/