From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752699AbcI1KGy (ORCPT ); Wed, 28 Sep 2016 06:06:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54600 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752116AbcI1KGr (ORCPT ); Wed, 28 Sep 2016 06:06:47 -0400 Message-ID: <57EB9635.8060103@redhat.com> Date: Wed, 28 Sep 2016 06:06:45 -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: Peter Zijlstra CC: Greg Kroah-Hartman , Borislav Petkov , linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, Len Brown , Andi Kleen , Jiri Olsa , Juergen Gross Subject: Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event References: <20160921130428.2e7bprll64vs6h2r@pd.tnic> <57E28BFF.8060107@redhat.com> <20160921140135.i5emid4qno2o6cre@pd.tnic> <57E3C78C.5040400@redhat.com> <20160922121039.l6lnhb53os2af27x@pd.tnic> <57E90A61.60402@redhat.com> <20160926115728.sdnvjaz3ty6xpsvr@pd.tnic> <57EA5BF4.1060508@redhat.com> <20160927134957.GB19759@kroah.com> <57EA8F96.6030303@redhat.com> <20160928064823.GR2794@worktop> In-Reply-To: <20160928064823.GR2794@worktop> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 28 Sep 2016 10:06:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/28/2016 02:48 AM, Peter Zijlstra wrote: > On Tue, Sep 27, 2016 at 11:26:14AM -0400, Prarit Bhargava wrote: >> I see now that the issue is not understanding the difference between physical >> and soft thread removal. I will write that up and get back to everyone. > > You don't seem to understand that from the kernels POV there is no such > distinction. > And I'm saying you're wrong. Unlike PCI, CPU sysfs unplug does not completely remove the device from the kernel's knowledge. If that were the case then /sys/devices/system/cpu/cpuX/online (and other files left after the unplug) wouldn't exist. If you do a physical removal (signaled via ACPI or interrupt) the entire device is removed from the kernel's POV. Yes, the sysfs removal is a subset of the physical removal. But the end result is very different. > There is only one unplug operation that caters to both cases. Therefore > unplug needs to assume the most stringent (ie. physical) for things to > work right. See last comment above. P.