linux-kernel - [PATCH] sched: topology: add input parameter for sched_domain_flags

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] [day] [month] [year] [list]

Message-ID: <SL2PR06MB3082B464A5D719DE78893DECBD1D9@SL2PR06MB3082.apcprd06.prod.outlook.com>
Date:   Mon, 28 Mar 2022 12:19:11 +0000
From:   王擎 <wangqing@...o.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [PATCH] sched: topology: add input parameter for
 sched_domain_flags_f()


>> From: Wang Qing <wangqing@...o.com>
>> 
>> sched_domain_flags_f() are statically set now, but actually, we can get a
>> lot of necessary information based on the cpu_map. e.g. we can know whether
>> its cache is shared.
>> 
>> Allows custom extension without affecting current.
>
>This all still makes absolutely no sense. The architecture builds these
>masks, the architecture is in charge of which flags function is called
>on which mask.
>
>Passing the mask back in means it lost the plot somewhere and doens't
>know wth it's doing anymore.

It is not passing the mask back, sched_domain_flags_f() doesn't use cpumask
at all, it always return fixed values. sd_topology_level select different 
sd_flag() to config, it's too primitive.

If an architecture can describe its cache topology clearly in every level,
the sd only need sched_domain_flags_f(cpumask) to get its ShPR flag.

Thanks,
Wang

>
>NAK