Messages in this thread | | | Date | Tue, 17 Jan 2023 18:39:03 +0530 | Subject | Re: [RFC PATCH V1 1/1] sched/numa: Enhance vma scanning logic | From | Raghavendra K T <> |
| |
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@amd.com> >> (initial patch to store pid information) >> >> Suggested-by: Mel Gorman <mgorman@techsingularity.net> >> Signed-off-by: Bharata B Rao <bharata@amd.com> >> Signed-off-by: Raghavendra K T <raghavendra.kt@amd.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.
| |