Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759197AbbBIB2I (ORCPT ); Sun, 8 Feb 2015 20:28:08 -0500 Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:42594 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755579AbbBIB2H (ORCPT ); Sun, 8 Feb 2015 20:28:07 -0500 Date: Mon, 9 Feb 2015 01:28:01 +0000 From: Will Deacon To: Daniel Thompson Cc: Thomas Gleixner , John Stultz , "linux-kernel@vger.kernel.org" , "patches@linaro.org" , "linaro-kernel@lists.linaro.org" , Sumit Semwal , Stephen Boyd , Steven Rostedt , Russell King , Catalin Marinas Subject: Re: [PATCH v4 2/5] sched_clock: Optimize cache line usage Message-ID: <20150209012801.GA13969@arm.com> References: <1421859236-19782-1-git-send-email-daniel.thompson@linaro.org> <1423396960-4824-1-git-send-email-daniel.thompson@linaro.org> <1423396960-4824-3-git-send-email-daniel.thompson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1423396960-4824-3-git-send-email-daniel.thompson@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1233 Lines: 28 On Sun, Feb 08, 2015 at 12:02:37PM +0000, Daniel Thompson wrote: > Currently sched_clock(), a very hot code path, is not optimized to > minimise its cache profile. In particular: > > 1. cd is not ____cacheline_aligned, > > 2. struct clock_data does not distinguish between hotpath and > coldpath data, reducing locality of reference in the hotpath, > > 3. Some hotpath data is missing from struct clock_data and is marked > __read_mostly (which more or less guarantees it will not share a > cache line with cd). > > This patch corrects these problems by extracting all hotpath data > into a separate structure and using ____cacheline_aligned to ensure > the hotpath uses a single (64 byte) cache line. Have you got any performance figures for this change, or is this just a theoretical optimisation? It would be interesting to see what effect this has on systems with 32-byte cachelines and also scenarios where there's contention on the sequence counter. Will -- 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/