From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753920AbcJKQtj (ORCPT ); Tue, 11 Oct 2016 12:49:39 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:34161 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752188AbcJKQth (ORCPT ); Tue, 11 Oct 2016 12:49:37 -0400 MIME-Version: 1.0 In-Reply-To: <20161010164543.GA30442@intel.com> References: <1475894763-64683-1-git-send-email-fenghua.yu@intel.com> <1475894763-64683-2-git-send-email-fenghua.yu@intel.com> <20161010164543.GA30442@intel.com> From: Nilay Vaish Date: Tue, 11 Oct 2016 11:48:56 -0500 Message-ID: Subject: Re: [PATCH v3 01/18] Documentation, ABI: Add a document entry for cache id To: "Luck, Tony" Cc: Fenghua Yu , Thomas Gleixner , "H. Peter Anvin" , Ingo Molnar , Peter Zijlstra , Stephane Eranian , Borislav Petkov , Dave Hansen , Shaohua Li , David Carrillo-Cisneros , Ravi V Shankar , Sai Prakhya , Vikas Shivappa , linux-kernel , x86 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10 October 2016 at 11:45, Luck, Tony wrote: > On Sat, Oct 08, 2016 at 12:11:08PM -0500, Nilay Vaish wrote: >> On 7 October 2016 at 21:45, Fenghua Yu wrote: >> > From: Fenghua Yu > >> > + caches typically exist per core, but there may not be a >> > + power of two cores on a socket, so these caches may be >> > + numbered 0, 1, 2, 3, 4, 5, 8, 9, 10, ... >> > + >> >> While it is ok that the caches are not numbered contiguously, it is >> unclear how this is related to number of cores on a socket being a >> power of 2 or not. > > That's a side effect of the x86 algorithm to generate the unique ID > which uses a shift to put the socket number in some upper bits while > leaving the "id within a socket" in the low bits. > > I don't think it worth documenting here, but I noticed that we don't > keep the IDs within a core contguous either. On my 24 core Broadwell > they are not 0 ... 23 then a gap from 24 to 31. I actually have on > socket 0: > > 0, 1, 2, 3, 4, 5 > 8, 9, 10, 11, 12, 13 > 16, 17, 18, 19, 20, 21 > 24, 25, 26, 27, 28, 29 > Thanks for the info. -- Nilay