linux-kernel - Re: [RFC PATCH 0/2] Hot page promotion optimization for large address space

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: <8b073658-268d-4d3e-bd94-3fe95c948bd9@amd.com>
Date: Fri, 12 Apr 2024 13:46:12 +0530
From: Bharata B Rao <bharata@....com>
To: "Huang, Ying" <ying.huang@...el.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 akpm@...ux-foundation.org, mingo@...hat.com, peterz@...radead.org,
 mgorman@...hsingularity.net, raghavendra.kt@....com,
 dave.hansen@...ux.intel.com, hannes@...xchg.org
Subject: Re: [RFC PATCH 0/2] Hot page promotion optimization for large address
 space

On 12-Apr-24 12:58 PM, Huang, Ying wrote:
> Bharata B Rao <bharata@....com> writes:
> 
>> On 03-Apr-24 2:10 PM, Huang, Ying wrote:
>>>> Here are the numbers for the 192nd chunk:
>>>>
>>>> Each iteration of 262144 random accesses takes around ~10ms
>>>> 512 such iterations are taking ~5s
>>>> numa_scan_seq is 16 when this chunk is accessed.
>>>> And no page promotions were done from this chunk. All the
>>>> time should_numa_migrate_memory() found the NUMA hint fault
>>>> latency to be higher than threshold.
>>>>
>>>> Are these time periods considered too short for the pages
>>>> to be detected as hot and promoted?
>>>
>>> Yes.  I think so.  This is burst accessing, not repeated accessing.
>>> IIUC, NUMA balancing based promotion only works for repeated accessing
>>> for long time, for example, >100s.
>>
>> Hmm... When a page is accessed 512 times over a period of 5s and it is
>> still not detected as hot. This is understandable if fresh scanning couldn't
>> be done as the accesses were bursty and hence they couldn't be captured via
>> NUMA hint faults. But here the access captured via hint fault is being rejected
>> as not hot because the scanning was done a while back. But I do see the challenge
>> here since we depend on scanning time to obtain the frequency-of-access metric.
> 
> Consider some pages that will be accessed once every 1 hour, should we
> consider it hot or not?  Will your proposed method deal with that
> correctly?

The proposed method removes the absolute time as a factor for the decision and instead
relies on the number of hint faults that have occurred since that page was scanned last.
As long as there are enough hint faults happening in that 1 hour (which means a lot many
other accesses have been captured in that 1 hour), that page shouldn't be considered as
hot. You did mention earlier about hint fault rate varying a lot and one thing I haven't
tried yet is to vary the fault threshold based on current or historical fault rate.

Regards,
Bharata.