From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754966AbcBHRo5 (ORCPT ); Mon, 8 Feb 2016 12:44:57 -0500 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:43833 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754604AbcBHRoy (ORCPT ); Mon, 8 Feb 2016 12:44:54 -0500 From: Al Grant To: Mathieu Poirier , Alexander Shishkin CC: Chunyan Zhang , "robh@kernel.org" , Mark Brown , Pratik Patel , Nicolas GUION , Jon Corbet , Mark Rutland , Mike Leach , "Jeremiassen, Tor" , Lyra Zhang , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-api@vger.kernel.org" , "linux-doc@vger.kernel.org" Subject: RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs Thread-Topic: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs Thread-Index: AQHRXls06GfJKYDiYkKs5UNxXFPUwJ8da1cAgABYTwCABKWfNoAACMBQ Date: Mon, 8 Feb 2016 17:44:49 +0000 Message-ID: References: <1454487337-30184-1-git-send-email-zhang.chunyan@linaro.org> <1454487337-30184-4-git-send-email-zhang.chunyan@linaro.org> <87mvrf5ngl.fsf@ashishki-desk.ger.corp.intel.com> <87twlj49k7.fsf@ashishki-desk.ger.corp.intel.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.157.245.195] x-microsoft-exchange-diagnostics: 1;DB4PR08MB0046;5:VcfZmsGJilpmE9dCqqRrObgnyZgHMtXfVobmdu/Plm0iIqzF4nHkzJUekcfuJJGK74lSDJd7ghdK4Lwn8CE3UPrz9lGRd6jI20Dw0v92yp3pSteBLiS/zh/ISUHlC/MrLTl1oooUnucRiX/IPhKU7Q==;24:QfUFuL14nEB9kEH9LF9woMwPKwuKjhdDK199PaByBuk98YqP8ye8gQJ/z1JizW8lLs1D9bUNMTIvHCB57KxXLBslTkWVHgDDpZM9lTWQLKY=;20:jW4r1sl0OjAMpehDqb8YrfAiDy0fQDQR/MPEgobrDOvQHR1LvbZUueH6mpD1avESJD413VmX03erWU0aEvxXH8QaRcv0IsnTie9yamrgia1OUyysQuF5b0Me2gAjXIFljGdlL4gxNp+/MIxb/i/uq6peJMgw/zBRrnK+azMfBGE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR08MB0046; x-ms-office365-filtering-correlation-id: ec17aec8-ebdc-467f-e73c-08d330af8ad1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046);SRVR:DB4PR08MB0046;BCL:0;PCL:0;RULEID:;SRVR:DB4PR08MB0046; x-forefront-prvs: 084674B2CF x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(40434004)(74316001)(4326007)(33656002)(87936001)(6116002)(10400500002)(1096002)(1220700001)(102836003)(3846002)(5002640100001)(66066001)(586003)(76576001)(106116001)(2906002)(93886004)(2900100001)(77096005)(2950100001)(54356999)(50986999)(76176999)(86362001)(5008740100001)(5004730100002)(3660700001)(3280700002)(5003600100002)(5001770100001)(40100003)(189998001)(92566002)(5001960100002)(5890100001)(122556002);DIR:OUT;SFP:1101;SCL:1;SRVR:DB4PR08MB0046;H:AM4PR08MB0785.eurprd08.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2016 17:44:49.4700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB0046 X-MC-Unique: QxvslUJ7SPi7ZKFQH4Mnog-1 Content-Type: text/plain; charset=UTF-8 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 u18Hj3uV029300 > Mike did write "master IDs are hardwired to individual cores and core security > states", which make assignment for one platform very static. > On the flip side those will change from one system to another. It depends on your perspective. From the perspective of a userspace process not pinned to a core, the master id will appear to vary dynamically and unpredictably as the thread migrates from one core to another. (That's actually useful if the decoder wants to know where the thread is running at any given point, as it can find that out for free, without the need to track migration events.) On the other hand if you are pinned (e.g. you're the kernel on a particular core, or you're a per-core worker thread in some thread pooling system) then you have a fixed master id, and then you can have one instance per core all using the same range of channel numbers, with the master id indicating the core - this saves on channel space compared to having to give each core its own range of channel space. Al IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.