From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753368AbdF0SpU (ORCPT ); Tue, 27 Jun 2017 14:45:20 -0400 Received: from mail.skyhub.de ([5.9.137.197]:53400 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753249AbdF0SpD (ORCPT ); Tue, 27 Jun 2017 14:45:03 -0400 Date: Tue, 27 Jun 2017 20:44:35 +0200 From: Borislav Petkov To: "Ghannam, Yazen" Cc: "Suthikulpanit, Suravee" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Duran, Leo" , Peter Zijlstra Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of socket Message-ID: <20170627184435.kf2dx4wvp2ojvupw@pd.tnic> References: <1498545653-6755-1-git-send-email-suravee.suthikulpanit@amd.com> <1498545653-6755-2-git-send-email-suravee.suthikulpanit@amd.com> <20170627104803.wlhsqhaylbeqod37@pd.tnic> <20170627134251.5ztfqqlm3rg6y7ql@pd.tnic> <2f3bf9f2-cbca-ca72-219a-13c6faf9d314@amd.com> <20170627174411.gheip4jmra2ihuhq@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 27, 2017 at 06:32:34PM +0000, Ghannam, Yazen wrote: > > you want all those threads to belong to a single scheduling group. > > Correct? > > > > Now that thing has a memory controller attached to it, correct? > > > > If so, why is this thing not a logical NUMA node, as described in SRAT/SLIT? > > > > If not, what does a NUMA node entail on Zen as described by SRAT/SLIT? > > I.e., what is the difference between the two things? I.e., how many dies as > > above are in a NUMA node? > > > > Now, SRAT should contain the assignment which core belongs to which node. > > Why is that not sufficient? > > > > Ok, that should be enough questions for now. Let's start with them. > > > > This group is a NUMA node. It is the "identity" NUMA node. Linux skips the Please be more specific. Which group exactly? Which question above are you answering? > identity NUMA node when finding the NUMA levels. This is fine as long as the > MC domain is equivalent to the identity NUMA node. However, this is not the > case on Zen systems. > > We could patch the sched/topology.c to not skip the identity NUMA node. > Though this will affect all systems not just AMD. We can always add a X86_FEATURE flag but we need to agree on what you guys are actually trying to change and why? -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.