From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753167AbdF0QXv (ORCPT ); Tue, 27 Jun 2017 12:23:51 -0400 Received: from mail-dm3nam03on0067.outbound.protection.outlook.com ([104.47.41.67]:14333 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751541AbdF0QXk (ORCPT ); Tue, 27 Jun 2017 12:23:40 -0400 From: "Duran, Leo" To: "'Borislav Petkov'" CC: "'Thomas Gleixner'" , "Suthikulpanit, Suravee" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "Ghannam, Yazen" , Peter Zijlstra Subject: RE: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of socket Thread-Topic: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of socket Thread-Index: AQHS7xBkV4oBSeGdVkqrXOQu4LK/EKI4h5KAgAAm3wCAABSjAIAAEzOggAALyQCAAACGEA== Date: Tue, 27 Jun 2017 16:23:16 +0000 Message-ID: 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> <20170627161156.yim2pxtyg7efrbef@pd.tnic> In-Reply-To: <20170627161156.yim2pxtyg7efrbef@pd.tnic> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alien8.de; dkim=none (message not signed) header.d=none;alien8.de; dmarc=none action=none header.from=amd.com; x-originating-ip: [165.204.77.1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DM5PR12MB1739;20:I9PlqxNeDKukVPLy3RbGIHwlE3cUmvsf4svOr5aVmajxAx+Q4EKyPjBdOKQmOlWvXbAYczL4gftfG/giqIOnVsDSR2y5IRAsn1EGQUI2gmwuQPUBwM/nVaDXKLOiIwK8KOPFkrqMUI8akjWsr2V3kkb0c9Nfudh7vZ+151T9gdJSnk+Na1lRdmDcY2orqKByjCQOnqctPLmmHW4468XZUnGWio9+rYmB2JQqvkvwURAcWAAZvS8XlfExiYdlkTE0 x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10009020)(6009001)(39400400002)(39450400003)(39850400002)(39410400002)(39860400002)(39840400002)(13464003)(24454002)(377454003)(4326008)(54906002)(77096006)(6436002)(110136004)(33656002)(38730400002)(8676002)(53936002)(6246003)(25786009)(8936002)(7736002)(9686003)(86362001)(81166006)(2900100001)(189998001)(3660700001)(5660300001)(14454004)(74316002)(305945005)(53546010)(7696004)(102836003)(6506006)(99286003)(66066001)(2906002)(6916009)(76176999)(229853002)(3280700002)(50986999)(93886004)(6116002)(55016002)(2950100002)(54356999)(478600001)(3846002)(122556003);DIR:OUT;SFP:1101;SCL:1;SRVR:DM5PR12MB1739;H:DM5PR12MB1243.namprd12.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; x-ms-office365-filtering-correlation-id: f6bbf60c-9251-40c8-97bb-08d4bd78d113 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095);SRVR:DM5PR12MB1739; x-ms-traffictypediagnostic: DM5PR12MB1739: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(9452136761055)(767451399110)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DM5PR12MB1739;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DM5PR12MB1739; x-forefront-prvs: 0351D213B3 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2017 16:23:16.6904 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1739 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v5RGO8Yq015651 Boris, Please see my comments below. Leo. > -----Original Message----- > From: Borislav Petkov [mailto:bp@alien8.de] > Sent: Tuesday, June 27, 2017 11:12 AM > To: Duran, Leo > Cc: 'Thomas Gleixner' ; Suthikulpanit, Suravee > ; x86@kernel.org; linux- > kernel@vger.kernel.org; Ghannam, Yazen ; > Peter Zijlstra > Subject: Re: [PATCH 1/2] x86/CPU/AMD: Present package as die instead of > socket > > On Tue, Jun 27, 2017 at 03:48:55PM +0000, Duran, Leo wrote: > > Basically, in our case a Package may contain more than one L3 (i.e., > > in hardware terms, there may more than one 'Core complex' in a 'Die'). > > The important point is that all logical processors (threads) that > > share an L3 have a common "cpu_llc_id". > > All that means nothing if it doesn't have any effect on scheduling. > > If moving the working set between L3s within the package, as you call it, is > not measureable, i.e., task migration, then we don't care. The whole exercise > is not about modelling the hardware topology accurately but for presenting > sufficient detailed topology to the scheduler so that it works optimally on > Zen. [Duran, Leo] My understanding is the intent of the vendor-specific CPU topology code (in our case, amd.c) is to accurately present topology to the kernel, based on the 'abstractions' the kernel has defined. (abstractions being terms like "Package", "cpu_llc_id", etc) It is then up-to code that consumes the kernel-defined abstraction to ensure optimal use of the returned topology information. That is, My understating is that it is *not* our job at the "amd.c" level to return information that influences the scheduler in any prescribed way. If that were the case, it would seem to me that the code consuming the returned topology information is 'broken', or that the defined abstractions are 'broken'. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply.