From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933823AbcIVL7c (ORCPT ); Thu, 22 Sep 2016 07:59:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43468 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933231AbcIVL73 (ORCPT ); Thu, 22 Sep 2016 07:59:29 -0400 Message-ID: <57E3C78C.5040400@redhat.com> Date: Thu, 22 Sep 2016 07:59:08 -0400 From: Prarit Bhargava User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Borislav Petkov CC: linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Greg Kroah-Hartman , Peter Zijlstra , Len Brown , Andi Kleen , Jiri Olsa , Juergen Gross Subject: Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event References: <1474457973-19536-1-git-send-email-prarit@redhat.com> <20160921130428.2e7bprll64vs6h2r@pd.tnic> <57E28BFF.8060107@redhat.com> <20160921140135.i5emid4qno2o6cre@pd.tnic> In-Reply-To: <20160921140135.i5emid4qno2o6cre@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 22 Sep 2016 11:59:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/21/2016 10:01 AM, Borislav Petkov wrote: > On Wed, Sep 21, 2016 at 09:32:47AM -0400, Prarit Bhargava wrote: >> This is not the right thing to do [1]. The topology directory should exist as >> long as the thread is present in the system. The thread (and its core) are >> still physically there, it's just that the thread is not available to the >> scheduler. The topology of the thread hasn't changed due to it being soft >> offlined this way. > > So far so good. > >> turbostat was modified to deal with the missing topology directory, and in tree >> utility cpupower prints out significantly less information when a thread is >> offline. > > Why does it do that? Why does an offlined core change that info? > > Concrete details please. > >> ISTR a powertop bug due to hotplug too. This makes these monitoring >> utilities a problem for users who want only one thread per core. > > one thread per core? What does that mean? System boots with (usually) with 2 threads/core. Some performance users want one thread per core. Since there is no "noht" option anymore, users use /sys to disable a thread on each core. > >> This now means that >> >> echo 0 > /sys/devices/system/cpu/cpu29/online >> >> will result in the thread's topology directory staying around until the struct >> device associated with it is destroyed upon a physical socket hotplug event. > > So your 2/2 says that on an offlined CPU, you have > > /sys/devices/system/cpu/cpu10/topology/core_id:3 > /sys/devices/system/cpu/cpu10/topology/core_siblings:0000 > /sys/devices/system/cpu/cpu10/topology/core_siblings_list: > /sys/devices/system/cpu/cpu10/topology/physical_package_id:0 > /sys/devices/system/cpu/cpu10/topology/thread_siblings:0000 > /sys/devices/system/cpu/cpu10/topology/thread_siblings_list: > > and this information is bollocks. core_siblings is 0, thread_siblings > is 0. You can just as well not have them there at all. core_siblings and thread_siblings are the online thread's sibling cores and threads that are available to the scheduler, and should be 0 when the thread is offline. That comes directly from reading the code. > > So is this whole jumping around just so that you can have a > /sys/devices/system/cpu/cpu10/topology directory and so that tools don't > get confused by it missing? Yes. > > So again, what exactly are those tools accessing and how does the > offlined cores puzzle them? > > A concrete example please: > See commit 20102ac5bee3 ("cpupower: cpupower monitor reports uninitialized values for offline cpus"). That patch papers over the bug of not being able to find core_id and physical_package_id for an offline thread. P.