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: <SL2PR06MB308222752B34227A070D4C29BDF79@SL2PR06MB3082.apcprd06.prod.outlook.com>
Date:   Fri, 22 Apr 2022 09:48:34 +0000
From:   王擎 <wangqing@...o.com>
To:     Sudeep Holla <sudeep.holla@....com>
CC:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [PATCH 1/2] arch_topology: support for describing cache topology from
 DT

> 
>On Thu, Apr 21, 2022 at 07:55:57AM -0700, Qing Wang wrote:
>> From: Wang Qing <wangqing@...o.com>
>> 
>> When ACPI is not enabled, we can get cache topolopy from DT like:
>> *             cpu0: cpu@000 {
>> *                     next-level-cache = <&L2_1>;
>> *                     L2_1: l2-cache {
>> *                              compatible = "cache";
>> *                             next-level-cache = <&L3_1>;
>> *                      };
>> *                     L3_1: l3-cache {
>> *                              compatible = "cache";
>> *                      };
>> *             };
>> *
>> *             cpu1: cpu@001 {
>> *                     next-level-cache = <&L2_1>;
>> *             };
>> *             ...
>> *             };
>> cache_topology hold the pointer describing "next-level-cache",
>> it can describe the cache topology of every level.
>
>As I mentioned before, I would like to avoid any duplication and see
>what can be reused from drivers/base/cacheinfo.c

I tried, but cacheinfo initialization is too late, 
we can discuss this part after 2/2 is approved.

>
>We can discuss and see how to proceed on that once we settle/agree on
>2/2. I don't want to waste your or my time if we don't end up using this.
>So let us look at this once we agree to push the sched related changes
>as we have used generic ones so far and you want to introduce arm64 specific
>levels. That requires some discussions and thoughts before we can finalise.
>
>Also I have mentioned you to keep Dietmar and Vincent in cc for all sched
>related changes which you failed to do again. I expect you fix that next
>time if you want them to help you in discussions and make any progress on
>this. Otherwise it may get ignored as you don't have all the right
>people in cc.

I found this, and have forwarded it to Dietmar and Vincent, 
I definitely will fix that next time.

Thanks,
Qing
>
>--
>Regards,
>Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ