From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754044AbbIJKWb (ORCPT ); Thu, 10 Sep 2015 06:22:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:35615 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269AbbIJKW3 (ORCPT ); Thu, 10 Sep 2015 06:22:29 -0400 Date: Thu, 10 Sep 2015 03:22:21 -0700 From: Davidlohr Bueso To: Rasmus Villemoes Cc: Thomas Gleixner , kbuild test robot , Sebastian Andrzej Siewior , Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: [PATCH] futex: eliminate cache miss from futex_hash() Message-ID: <20150910102220.GB19736@linux-q0g1.site> References: <1441834601-13633-1-git-send-email-linux@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1441834601-13633-1-git-send-email-linux@rasmusvillemoes.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 09 Sep 2015, Rasmus Villemoes wrote: >futex_hash() references two global variables: the base pointer >futex_queues and the size of the array futex_hashsize. The latter is >marked __read_mostly, while the former is not, so they are likely to >end up very far from each other. This means that futex_hash() is >likely to encounter two cache misses. > >We could mark futex_queues as __read_mostly as well, but that doesn't >guarantee they'll end up next to each other (and even if they do, they >may still end up in different cache lines). So put the two variables >in a small singleton struct with sufficient alignment and mark that as >__read_mostly. This really doesn't have much practical effect -- not even on larger boxes, where such things matter. For instance, I ran the patch on a 60-core IvyBridge with 'perf-bench futex', for which futex-hash particularly benefits in good data layout (ie our current smp alignment). http://linux-scalability.org/futex-__futex_data/ I think we should leave it as is. Thanks, Davidlohr