[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <06cb753b-f64f-3679-b365-fbf346cbf828@amd.com>
Date: Tue, 17 Jan 2023 18:39:03 +0530
From: Raghavendra K T <raghavendra.kt@....com>
To: David Hildenbrand <david@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org
Cc: Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
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>,
Valentin Schneider <vschneid@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Matthew Wilcox <willy@...radead.org>,
Vlastimil Babka <vbabka@...e.cz>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Peter Xu <peterx@...hat.com>, xu xin <cgel.zte@...il.com>,
Yu Zhao <yuzhao@...gle.com>, Colin Cross <ccross@...gle.com>,
Arnd Bergmann <arnd@...db.de>, Hugh Dickins <hughd@...gle.com>,
Bharata B Rao <bharata@....com>,
Disha Talreja <dishaa.talreja@....com>
Subject: Re: [RFC PATCH V1 1/1] sched/numa: Enhance vma scanning logic
On 1/17/2023 4:44 PM, David Hildenbrand wrote:
> On 16.01.23 03:25, Raghavendra K T wrote:
>> During the Numa scanning make sure only relevant vmas of the
>> tasks are scanned.
>>
>> Logic:
>> 1) For the first two time allow unconditional scanning of vmas
>> 2) Store recent 4 unique tasks (last 8bits of PIDs) accessed the vma.
>> False negetives in case of collison should be fine here.
>> 3) If more than 4 pids exist assume task indeed accessed vma to
>> to avoid false negetives
>>
>> Co-developed-by: Bharata B Rao <bharata@....com>
>> (initial patch to store pid information)
>>
>> Suggested-by: Mel Gorman <mgorman@...hsingularity.net>
>> Signed-off-by: Bharata B Rao <bharata@....com>
>> Signed-off-by: Raghavendra K T <raghavendra.kt@....com>
>> ---
>> include/linux/mm_types.h | 2 ++
>> kernel/sched/fair.c | 32 ++++++++++++++++++++++++++++++++
>> mm/memory.c | 21 +++++++++++++++++++++
>> 3 files changed, 55 insertions(+)
>>
>> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
>> index 500e536796ca..07feae37b8e6 100644
>> --- a/include/linux/mm_types.h
>> +++ b/include/linux/mm_types.h
>> @@ -506,6 +506,8 @@ struct vm_area_struct {
>> struct mempolicy *vm_policy; /* NUMA policy for the VMA */
>> #endif
>> struct vm_userfaultfd_ctx vm_userfaultfd_ctx;
>> + unsigned int accessing_pids;
>> + int next_pid_slot;
>> } __randomize_layout;
>
> What immediately jumps at me is the unconditional grow of a VMA by 8
> bytes. A process with 64k mappings consumes 512 KiB more of memory,
> possibly completely unnecessarily.
>
> This at least needs to be fenced by CONFIG_NUMA_BALANCING.
>
Thanks for the review David. Good point.. I do agree. I see I will have
to fence further in memory.c only since fair.c is already taken care.
Powered by blists - more mailing lists