linux-kernel - Re: [RFC] Perfomance varies according to sysctl_sched_migration

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5be9d830-d6f4-6c2e-278f-940baeb57d89@hisilicon.com>
Date:   Tue, 14 Sep 2021 20:35:28 +0800
From:   Yicong Yang <yangyicong@...ilicon.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     <mingo@...hat.com>, <juri.lelli@...hat.com>,
        <vincent.guittot@...aro.org>, <dietmar.eggemann@....com>,
        <rostedt@...dmis.org>, <bsegall@...gle.com>, <mgorman@...e.de>,
        <bristot@...hat.com>, <21cnbao@...il.com>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
        <prime.zeng@...wei.com>,
        "guodong.xu@...aro.org" <guodong.xu@...aro.org>
Subject: Re: [RFC] Perfomance varies according to sysctl_sched_migration_cost

On 2021/9/14 19:30, Peter Zijlstra wrote:
> On Tue, Sep 14, 2021 at 03:27:09PM +0800, Yicong Yang wrote:
>> 2. The ABI now has been removed from sysctl and moved to debugfs. As tuning this can improve the performance
>>    of some workloads on some platforms, maybe it's better to make it a formal sysctl again with docs?
> 
> It never was an ABI, there is nothing to restore. It has always been
> CONFIG_SCHED_DEBUG.
> 

It's right that CONIG_SCHED_DEBUG is on for most releases and it's same to tune
it through debugfs. So I'm not with a strong heart to restore it but just curious
about this magic value since it does have some influence when tuning this on my platform.

> I'm open to topology based improvements to the code, but I don't think
> user tunables are a good way.
> 

sure, it's better to make the scheduler topology adapted rather than manually tuned, but
certainly it's not that easy to achieve. Maybe I can investigate the whole story
first, seems we didn't use a constant migration_cost_ns at very beginning, to see if there's
any inspiration.

Thanks.

> .
>