summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorMel Gorman <mgorman@techsingularity.net>2023-10-10 09:31:39 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-10-04 16:29:21 +0200
commit707e9a6c880f82d17a684278b8842b08f885c203 (patch)
treed0473de7aadc9d5c579a03d88e5d26680a2596c7 /kernel
parentba4eb7f25886e55c9bc183214e0b107b834b5503 (diff)
downloadlinux-707e9a6c880f82d17a684278b8842b08f885c203.tar.gz
linux-707e9a6c880f82d17a684278b8842b08f885c203.tar.bz2
linux-707e9a6c880f82d17a684278b8842b08f885c203.zip
sched/numa: Rename vma_numab_state::access_pids[] => ::pids_active[], ::next_pid_reset => ::pids_active_reset
[ Upstream commit f3a6c97940fbd25d6c84c2d5642338fc99a9b35b ] The access_pids[] field name is somewhat ambiguous as no PIDs are accessed. Similarly, it's not clear that next_pid_reset is related to access_pids[]. Rename the fields to more accurately reflect their purpose. [ mingo: Rename in the comments too. ] Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20231010083143.19593-3-mgorman@techsingularity.net Stable-dep-of: f22cde4371f3 ("sched/numa: Fix the vma scan starving issue") Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'kernel')
-rw-r--r--kernel/sched/fair.c12
1 files changed, 6 insertions, 6 deletions
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 5fc0d9cc9d9d..d07fb0a0da80 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3200,7 +3200,7 @@ static bool vma_is_accessed(struct vm_area_struct *vma)
if (READ_ONCE(current->mm->numa_scan_seq) < 2)
return true;
- pids = vma->numab_state->access_pids[0] | vma->numab_state->access_pids[1];
+ pids = vma->numab_state->pids_active[0] | vma->numab_state->pids_active[1];
return test_bit(hash_32(current->pid, ilog2(BITS_PER_LONG)), &pids);
}
@@ -3316,7 +3316,7 @@ static void task_numa_work(struct callback_head *work)
msecs_to_jiffies(sysctl_numa_balancing_scan_delay);
/* Reset happens after 4 times scan delay of scan start */
- vma->numab_state->next_pid_reset = vma->numab_state->next_scan +
+ vma->numab_state->pids_active_reset = vma->numab_state->next_scan +
msecs_to_jiffies(VMA_PID_RESET_PERIOD);
}
@@ -3337,11 +3337,11 @@ static void task_numa_work(struct callback_head *work)
* vma for recent access to avoid clearing PID info before access..
*/
if (mm->numa_scan_seq &&
- time_after(jiffies, vma->numab_state->next_pid_reset)) {
- vma->numab_state->next_pid_reset = vma->numab_state->next_pid_reset +
+ time_after(jiffies, vma->numab_state->pids_active_reset)) {
+ vma->numab_state->pids_active_reset = vma->numab_state->pids_active_reset +
msecs_to_jiffies(VMA_PID_RESET_PERIOD);
- vma->numab_state->access_pids[0] = READ_ONCE(vma->numab_state->access_pids[1]);
- vma->numab_state->access_pids[1] = 0;
+ vma->numab_state->pids_active[0] = READ_ONCE(vma->numab_state->pids_active[1]);
+ vma->numab_state->pids_active[1] = 0;
}
do {