linux-kernel - Re: [RFC v2 PATCH 4/5] vmstat: add page-cache numa hints

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: <a542f29b-8b9d-4287-b6df-1f4d09423c3e@linux.ibm.com>
Date: Sun, 29 Dec 2024 20:27:39 +0530
From: Donet Tom <donettom@...ux.ibm.com>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org, nehagholkar@...a.com,
        abhishekd@...a.com, kernel-team@...a.com, david@...hat.com,
        nphamcs@...il.com, akpm@...ux-foundation.org, hannes@...xchg.org,
        kbusch@...a.com, ying.huang@...ux.alibaba.com
Subject: Re: [RFC v2 PATCH 4/5] vmstat: add page-cache numa hints


On 12/27/24 21:19, Gregory Price wrote:
> On Fri, Dec 27, 2024 at 04:18:24PM +0530, Donet Tom wrote:
>> On 12/11/24 03:07, Gregory Price wrote:
> ... snip ...
>>> +		NUMA_HINT_PAGE_CACHE,
>>> +		NUMA_HINT_PAGE_CACHE_LOCAL,
>>>    		NUMA_PAGE_MIGRATE,
> ... snip ...
>>>    	if (folio_nid(folio) == numa_node_id()) {
>>> -		count_vm_numa_event(NUMA_HINT_FAULTS_LOCAL);
>>> +		count_vm_numa_event(NUMA_HINT_TYPE_LOCAL(vmf));
>> I have tested this patch series on my system with my test program. I am able
>> to see unmapped page cache pages are getting promoted.
>> numa_hint_faults2269numa_hint_faults_local2245numa_hint_page_cache1244numa_hint_page_cache_local0numa_pages_migrated4501
>>
>> In my test result numa_hint_page_cache_local is 0. I am seeing
>> numa_hint_page_cache_local will only be incremented if the folio's
>> node and the process's running node are the same. This condition
>> does not occur in the current implementation, correct?
>>
> I did not want to assume we'd never use this interface where such a
> scenario could occur - so i wanted to:
>
>    a) make such a scenario visible
>    b) make the code consistent with existing fault counts
Understood, thank you for clarifying!
>
> I'm fine removing it.  It's hard to know if this interface ever gets
> called with that scenario occurringwithout capturing the data.
>
> ~Gregory
>