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: <146a1a64-7925-008f-a817-fe0860b30105@arm.com>
Date:   Wed, 30 Mar 2022 17:44:10 +0100
From:   James Morse <james.morse@....com>
To:     Reinette Chatre <reinette.chatre@...el.com>, x86@...nel.org,
        linux-kernel@...r.kernel.org
Cc:     Fenghua Yu <fenghua.yu@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        H Peter Anvin <hpa@...or.com>,
        Babu Moger <Babu.Moger@....com>,
        shameerali.kolothum.thodi@...wei.com,
        Jamie Iles <jamie@...iainc.com>,
        D Scott Phillips OS <scott@...amperecomputing.com>,
        lcherian@...vell.com, bobo.shaobowang@...wei.com,
        tan.shaopeng@...itsu.com
Subject: Re: [PATCH v3 12/21] x86/resctrl: Calculate bandwidth from the
 previous __mon_event_count() chunks

Hi Reinette,

On 05/03/2022 00:27, Reinette Chatre wrote:
> On 2/17/2022 10:21 AM, James Morse wrote:
>> mbm_bw_count() is only called by the mbm_handle_overflow() worker once a
>> second. It reads the hardware register, calculates the bandwidth and
>> updates m->prev_bw_msr which is used to hold the previous hardware register
>> value.
>>
>> Operating directly on hardware register values makes it difficult to make
>> this code architecture independent, so that it can be moved to /fs/,
>> making the mba_sc feature something resctrl supports with no additional
>> support from the architecture.
>> Prior to calling mbm_bw_count(), mbm_update() reads from the same hardware
>> register using __mon_event_count().
>>
>> Change mbm_bw_count() to use the current chunks value most recently saved by
>> __mon_event_count(). This removes an extra call to __rmid_read().
> 
>> Instead of using m->prev_msr to calculate the number of chunks seen,
>> use the rr->val that was updated by __mon_event_count(). This removes a extra
>> calls to mbm_overflow_count() and get_corrected_mbm_count().
> 
> "removes a extra calls" -> "removes an extra call" ?
> 
> __mon_event_count() ends with "rr->val += get_corrected_mbm_count()" and
> it is called twice by mbm_update(). The intention in this change is for
> mbm_bw_count() to benefit from the rmid read done just before ...
> but would using rr->val within mbm_bw_count() not result in it getting
> data from both rmid reads due to the increment?

Yes, bother. I thought those were mutually exclusive, but its __mon_event_count() that
uses a different struct mbm_state for each set of raw values, not mbm_update().

[...]

> Should rr.val perhaps be reset before each __mon_event_count() call instead of
> just at the beginning of mbm_update()?

Yes. This is because the struct rmid_read is just to allow __mon_event_count() to do its
thing, nothing used to read those values.


>> Calculating bandwidth like this means mbm_bw_count() no longer operates
>> on hardware register values directly.


Thanks!

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ