On 2/7/2023 12:11 PM, Raghavendra K T wrote:
On 2/4/2023 11:44 PM, Raghavendra K T wrote:
On 2/3/2023 4:45 PM, Peter Zijlstra wrote:
On Wed, Feb 01, 2023 at 01:32:21PM +0530, Raghavendra K T wrote:
[...]
+ if (!vma_is_accessed(vma))
+ continue;
+
do {
start = max(start, vma->vm_start);
end = ALIGN(start + (pages << PAGE_SHIFT), HPAGE_SIZE);
This feels wrong, specifically we track numa_scan_offset per mm, now, if
we divide the threads into two dis-joint groups each only using their
own set of vmas (in fact quite common for workloads with proper data
partitioning) it is possible to consistently sample one set of threads
and thus not scan the other set of vmas.
It seems somewhat unlikely, but not impossible to create significant
unfairness.
Agree, But that is the reason why we want to allow first few
unconditional scans Or am I missing something?
Thinking further, may be we can summarize the different aspects of
thread/ two disjoint set case itself into:
1) Unfairness because of way in which threads gets opportunity
to scan.
2) Disjoint set of vmas in the partition set could be of different sizes
3) Disjoint set of vmas could be associated with different number of
threads
Each of above can potentially help or make some thread do heavy lifting
but (2), and (3). is what I think we are trying to be Okay with by
making sure tasks mostly do not scan others' vmas
(1) could be a real issue (though I know that there are many places we
have corrected the issue by introducing offset in p->numa_next_scan)
but how the distribution looks now practically, I take it as a TODO and
post.
Hello PeterZ,
Sorry to come back little late with Data for how unfair are we when we
have two disjoint set of groups mentioned above:
Program I tested with:
1. 128/256 thread program divided into two sets each accessing
different set of memory (set0, set1) from node1 and node2 to induce
migration (8GB divided into 4GB each].
Total iteration per thread was around 2048 to make sure for
128 thread: program ran around 8 min
256 thread: program ran around 17/18 min
SUT: 128 core 256 CPU Milan with 2 nodes
Some of the observations:
1) Total number of threads which gets access to scan in the entire
program span was around 50-62%
for e.g. 128 thread case total tasks got access to scan was around 74-84
for 256 thread range was 123-146
2) There was a little bias towards set 1 always (the threads from where
remote faults occurred)
In summary: I do see that access to VMAs from disjoint sets is not fully
fair, But on the other hand it is not very bad too. There is definitely
some scope or possibility to explore/improve fairness in this area
further.
Posting result for one of the 128 threads: (base 6.1.0 vanilla)
column1: frequency
column2: PID
set 0 threads
1 5906
1 5908
2 5912
1 5914
1 5916
1 5918
1 5926
2 5928
3 5932
3 5938
1 5940
1 5944
2 5948
2 5950
1 5956
1 5962
1 5974
1 5978
1 5992
1 6004
1 6006
1 6008
1 6012
3 6014
1 6016
2 6026
2 6028
1 6030
set 1 threads
3 5907
5 5909
2 5911
4 5913
7 5915
2 5917
3 5919
5 5921
3 5923
2 5925
4 5927
4 5929
3 5931
3 5933
2 5935
7 5937
4 5939
3 5941
4 5943
1 5945
2 5947
1 5949
1 5951
2 5953
1 5955
1 5957
1 5959
1 5961
1 5963
1 5965
1 5967
1 5969
1 5971
2 5975
2 5979
2 5981
2 5983
5 5993
5 5995
11 5997
1 5999
6 6003
4 6005
3 6007
1 6013
1 6015
3 6017
1 6019
1 6021
1 6023
6 6027
4 6029
4 6031
1 6033
PS: I have also tested above applying V3 patch (which incorporates your
suggestions), have not seen much deviation in observation with patch.
Thanks
- Raghu
