lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1370aa29-2b86-a199-05b9-a1995d65f966@arm.com>
Date:   Mon, 10 Sep 2018 12:05:52 +0100
From:   Qais Yousef <qais.yousef@....com>
To:     Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
        Vincent Guittot <vincent.guittot@...aro.org>
Cc:     peterz@...radead.org, mingo@...hat.com,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 3/4] sched/topology: remove smt_gain

On 04/09/18 11:37, Srikar Dronamraju wrote:
> * Vincent Guittot <vincent.guittot@...aro.org> [2018-09-04 11:36:26]:
>
>> Hi Srikar,
>>
>> Le Tuesday 04 Sep 2018 à 01:24:24 (-0700), Srikar Dronamraju a écrit :
>>> However after this change, capacity_orig of each SMT thread would be
>>> 1024. For example SMT 8 core capacity_orig would now be 8192.
>>>
>>> smt_gain was suppose to make a multi threaded core was slightly more
>>> powerful than a single threaded core. I suspect if that sometimes hurt
>> Is there system with both single threaded and multi threaded core ?
>> That was the main open point for me (and for Qais too)
>>
> I dont know of any systems that have come with single threaded and
> multithreaded. However some user can still offline few threads in a core
> while leaving other cores untouched. I dont really know why somebody
> would want to do it.  For example, some customer was toying with SMT 3
> mode in a SMT 8 power8 box.

What was the customer trying to achieve by this? Did this end up being 
useful?

If we get mixed SMT 3 and SMT 8 in the system we might have issues, but 
again I don't see how this makes sense from system point of view. I 
don't think power savings will be significant by turning off few 
hardware threads since the core which I'd expect to be the main energy 
consumer is still on. From performance perspective, SMT 3 might have 
less contention (hence better 'performance'), but we don't do anything 
special to decide to schedule work in this case to take advantage of 
that. So I don't think the setup is useful to cater for or encourage.

-- 
Qais Yousef

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ