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
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
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
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
On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote:
> Yes. But *where* is it relative to the cores and socket(s)?
And you need that information because...
> > If you need to show the package id, you still iterate over the core
> > numbers in an increasing order and show '*' for the
On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote:
> Yes. But *where* is it relative to the cores and socket(s)?
And you need that information because...
> > If you need to show the package id, you still iterate over the core
> > numbers in an increasing order and show '*' for the
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.
No need - we understand the issue.
What I don't understand is what
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.
No need - we understand the issue.
What I don't understand is what
On 09/27/2016 09:49 AM, Greg Kroah-Hartman wrote:
> On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote:
>> On 09/26/2016 07:57 AM, Borislav Petkov wrote:
>>> $ echo 0 > /sys/devices/system/cpu/cpu2/online
>>
>> This results in the topology directory being destroyed. It shouldn't be
On 09/27/2016 09:49 AM, Greg Kroah-Hartman wrote:
> On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote:
>> On 09/26/2016 07:57 AM, Borislav Petkov wrote:
>>> $ echo 0 > /sys/devices/system/cpu/cpu2/online
>>
>> This results in the topology directory being destroyed. It shouldn't be
On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote:
> On 09/26/2016 07:57 AM, Borislav Petkov wrote:
> > $ echo 0 > /sys/devices/system/cpu/cpu2/online
>
> This results in the topology directory being destroyed. It shouldn't be --
> the
> socket and core are still there. If you
On Tue, Sep 27, 2016 at 07:45:56AM -0400, Prarit Bhargava wrote:
> On 09/26/2016 07:57 AM, Borislav Petkov wrote:
> > $ echo 0 > /sys/devices/system/cpu/cpu2/online
>
> This results in the topology directory being destroyed. It shouldn't be --
> the
> socket and core are still there. If you
On Tue, Sep 27, 2016 at 07:47:56AM -0400, Prarit Bhargava wrote:
> There's a difference between soft remove (via sysfs) and a true hot remove
> operation (where the whole thing is physically removed). Soft remove only
> results in the processor being made "not available" to the scheduler.
How
On Tue, Sep 27, 2016 at 07:47:56AM -0400, Prarit Bhargava wrote:
> There's a difference between soft remove (via sysfs) and a true hot remove
> operation (where the whole thing is physically removed). Soft remove only
> results in the processor being made "not available" to the scheduler.
How
On 09/26/2016 07:59 AM, Peter Zijlstra wrote:
> On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
>>> But then code which reads those will have to *know* that those cores are
>>> offline - otherwise it would be confused by what it is reading there.
>>
>> When offline,
On 09/26/2016 07:59 AM, Peter Zijlstra wrote:
> On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
>>> But then code which reads those will have to *know* that those cores are
>>> offline - otherwise it would be confused by what it is reading there.
>>
>> When offline,
On 09/26/2016 07:57 AM, Borislav Petkov wrote:
> On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
>> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
>> when online is 0, topology disappears so there is no way to determine _the
>> location_ of the
On 09/26/2016 07:57 AM, Borislav Petkov wrote:
> On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
>> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
>> when online is 0, topology disappears so there is no way to determine _the
>> location_ of the
On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
> > But then code which reads those will have to *know* that those cores are
> > offline - otherwise it would be confused by what it is reading there.
>
> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
> > But then code which reads those will have to *know* that those cores are
> > offline - otherwise it would be confused by what it is reading there.
>
> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
> when online is 0, topology disappears so there is no way to determine _the
> location_ of the offline'd thread.
What does "the location" mean exactly?
On Mon, Sep 26, 2016 at 07:45:37AM -0400, Prarit Bhargava wrote:
> When offline, /sys/devices/system/cpuX/cpu/online is 0. The problem is that
> when online is 0, topology disappears so there is no way to determine _the
> location_ of the offline'd thread.
What does "the location" mean exactly?
On 09/22/2016 08:10 AM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote:
>> 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
On 09/22/2016 08:10 AM, Borislav Petkov wrote:
> On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote:
>> 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
On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote:
> 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.
I see.
> core_siblings and
On Thu, Sep 22, 2016 at 07:59:08AM -0400, Prarit Bhargava wrote:
> 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.
I see.
> core_siblings and
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
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
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
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
On 09/21/2016 09:04 AM, Borislav Petkov wrote:
> On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote:
>> The information in /sys/devices/system/cpu/cpuX/topology
>> directory is useful for userspace monitoring applications and in-tree
>> utilities like cpupower & turbostat.
>>
>>
On 09/21/2016 09:04 AM, Borislav Petkov wrote:
> On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote:
>> The information in /sys/devices/system/cpu/cpuX/topology
>> directory is useful for userspace monitoring applications and in-tree
>> utilities like cpupower & turbostat.
>>
>>
On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote:
> The information in /sys/devices/system/cpu/cpuX/topology
> directory is useful for userspace monitoring applications and in-tree
> utilities like cpupower & turbostat.
>
> When down'ing a CPU the
On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote:
> The information in /sys/devices/system/cpu/cpuX/topology
> directory is useful for userspace monitoring applications and in-tree
> utilities like cpupower & turbostat.
>
> When down'ing a CPU the
The information in /sys/devices/system/cpu/cpuX/topology
directory is useful for userspace monitoring applications and in-tree
utilities like cpupower & turbostat.
When down'ing a CPU the /sys/devices/system/cpu/cpuX/topology directory is
removed during the CPU_DEAD hotplug callback in the
The information in /sys/devices/system/cpu/cpuX/topology
directory is useful for userspace monitoring applications and in-tree
utilities like cpupower & turbostat.
When down'ing a CPU the /sys/devices/system/cpu/cpuX/topology directory is
removed during the CPU_DEAD hotplug callback in the
36 matches
Mail list logo
