Fix an issue with the last level cache values on Linux running on certain AMD Processors by mrsharm · Pull Request #108492 · dotnet/runtime

mrsharm · 2024-10-02T20:00:38Z

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm · 2024-10-02T20:00:38Z

Fixes: #76290

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm · 2024-10-02T20:00:38Z

Fixes: #76290

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm · 2024-10-02T20:00:38Z

Fixes: #76290

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm · 2024-10-02T20:00:38Z

Fixes: #76290

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm · 2024-10-02T20:00:38Z

Fixes: #76290

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm · 2024-10-02T20:00:38Z

Fixes: #76290

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm · 2024-10-02T20:00:38Z

Fixes: #76290

Problem Details

We recently discovered an issue that affects Unix based VMs where we are taking the host’s (as opposed to the VM’s) for certain AMD processor's last level cache size to be used in the GetLogicalProcessorCacheSizeFromOS call to discern the gen0 budget for both WKS and SVR. This is because sysconf, the method we first try in GetLogicalProcessorCacheSizeFromOS, gets us the last level cache of the host machine as opposed to the fallback code path that reads the value of /sys/devices/system/cpu/cpu0/cache/index{LastLevelCache}/size. Consequently, the gen0 budgets are significantly different between Unix VMs and Windows using certain AMD processors on the same machine and the further implication of this is that we are probably setting much larger value than expected for the Gen0 budget for the GC running on Unix based VMs.

The details from my v16 CPU based DevBox with an AMD EPYC 7763 64 Core Processor running Ubuntu 22.04.3 via WSL are as follows:

sysconf returns the last cache size (L3) for the host machine (AMD EPYC™ 7763 – specs are here) as 256 MB.
- Can be repro’d on the command line using:
  getconf -a | grep “LEVEL3_CACHE_SIZE” => LEVEL3_CACHE_SIZE 268435456
Reading /sys/devices/system/cpu/cpu0/cache/index3/size returns 32 MiB, the same as the result from GetLogicalProcessorCacheSizeFromOS from Windows that calls GetLogicalProcessorInformation function (sysinfoapi.h) - Win32 apps | Microsoft Learn.
- Can be repro’d on the command line using lscpu => L3: 32 MiB (1 instance)

How To Check for the Issue

Get sysconf output: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the L3 (or if available, L4) cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

Solution

By default, with no configuration changes, first try to read in the cache information from sysfs and if that fails, fall back to the heuristic we use to compute the value for the ARM* cases.
A new configuration DOTNET_GCCacheSizeFromSysConf can be set to 1 to revert to the current behavior i.e., using sysconf to obtain the last level cache.

Performance Testing

Ran with the following GCPerfSim configurations for SVR: -tc 28 -tagb 100 -tlgb 0 -lohar 0-pohar 0 -sohsr 100-4000 -lohsr 102400-204800 -pohsr 100-204800 -sohsi 0 -lohsi 0 -pohsi 0 -sohpi 0 -lohpi 0 -sohfi 0 -lohfi 0 -pohfi 0 -allocType reference -testKind time

Metric	Not With SysConf	With SysConf
Peak Heap Size (MB)	339.458	2656.194
% Pause Time in GC	39.0	7.7

Maoni0 · 2024-10-05T06:48:10Z

the rest looks okay to me.. would be great if @janvorli could take a look.

…runtime into lastlevelcache_refactor

janvorli · 2024-10-08T12:17:18Z

There is one thing I keep thinking about. Would it be a problem in case the /sys/devices/system/cpu/cpu0/cache is not present to still read the size from sysconf? In other words, to let the new config knob control just the order in which we try to use the /sys/devices/system/cpu/cpu0/cache and sysconf? I wonder if in the case the /sys/devices/system/cpu/cpu0/cache is missing, the heuristic fallback would give us a reasonable value.

Maoni0 · 2024-10-09T04:52:19Z

the way I look at this is from the user's POV the values from sysconf is simply incorrect. so it'd be better to just take the heuristic values. another option is to treat sysconf to always give us the full cache sizes and check to see how many cores this process is actually allowed to use and get a ratio (so if sysconf reports 128mb and 64 cores, our process can only use 8 cores, we take 1/8 of 128mb).

janvorli · 2024-10-09T08:23:11Z

I would rather avoid introducing this new kind of heuristic, because it depends on the internal topology of the processor. One of the cases we were seeing this issue occurred on some AMD processors, because they have 4 separate 3rd level caches where each one is shared by 1/4 of the cores. In this case, the customer was using the full CPU and still the sysconf was returning a sum of the 3rd level cache sizes, it means 4 times higher value.
So let's keep this change as is.

mrsharm · 2024-11-05T19:22:54Z

How To Check for the Issue

Get sysconf output for the last level cache size: getconf -a | grep "LEVEL"
The full output of lscpu
Check if the last level cache size is the same from sysconf and that from lscpu.
If the values are different, the issue exists.

mrsharm · 2024-11-12T18:23:19Z

/backport to release/9.0-staging

github-actions · 2024-11-12T18:23:32Z

Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11803383363

github-actions · 2024-11-12T18:25:10Z

@mrsharm backporting to release/9.0-staging failed, the patch most likely resulted in conflicts:

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Started work on the Last Level Cache optimization
.git/rebase-apply/patch:112: trailing whitespace.
#endif 
.git/rebase-apply/patch:152: trailing whitespace.
// It seems ok to set the same default sizes when the cache info isn’t available on the /sys/ path like we did with arm. .git/rebase-apply/patch:166: trailing whitespace.
warning: 3 lines add whitespace errors.
Using index info to reconstruct a base tree...
M	src/coreclr/gc/gcconfig.h
Falling back to patching base and 3-way merge...
Auto-merging src/coreclr/gc/gcconfig.h
CONFLICT (content): Merge conflict in src/coreclr/gc/gcconfig.h
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 Started work on the Last Level Cache optimization
Error: The process '/usr/bin/git' failed with exit code 128

Please backport manually!

github-actions · 2024-11-12T18:25:10Z

@mrsharm an error occurred while backporting to release/9.0-staging, please check the run log for details!

Error: git am failed, most likely due to a merge conflict.

…tain AMD Processors (dotnet#108492)

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

mrsharm added 7 commits September 30, 2024 13:49

Started work on the Last Level Cache optimization
706d07f

Added a link to Config to test
ca253a4

Made progress and have the result functional
5567765

Incorporated more feedback
5c81ec1

Fix order of the deps in unix
23f816b

Added the parent dir to build
d5c2d95

Fixed up description of new configuration
6b7a7e2

ghost added the area-GC-coreclr label Oct 2, 2024

dotnet-policy-serviceBot assigned mrsharm Oct 2, 2024

mrsharm commented Oct 2, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm requested review from Maoni0, cshung, janvorli, mangod9 and markples October 2, 2024 21:12

Removed printf
9f801b2

mrsharm marked this pull request as ready for review October 4, 2024 19:19

Merge branch 'main' into lastlevelcache_refactor
a576979

build-analysisBot mentioned this pull request Oct 4, 2024
restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879
Closed
3 tasks

mrsharm changed the title ~~[Work in Progress] Fix an issue with the last level cache values on Linux running on certain AMD Processors~~Fix an issue with the last level cache values on Linux running on certain AMD ProcessorsOct 4, 2024

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

Maoni0 reviewed Oct 5, 2024
View reviewed changes

Comment threadsrc/coreclr/gc/unix/gcenv.unix.cpp Outdated

mrsharm added 2 commits October 7, 2024 22:47

Addressed feedback
2e3a0c6

Merge branch 'lastlevelcache_refactor' ofhttps://github.com/mrsharm/…
f945247
…runtime into lastlevelcache_refactor

Fixed build break
fe7f9cd

Maoni0 approved these changes Oct 9, 2024
View reviewed changes

mrsharm merged commit 4f69316 into dotnet:mainOct 11, 2024

DrewScoggins mentioned this pull request Oct 15, 2024
[Perf] Linux/x64: 35 Regressions on 10/11/2024 8:14:13 PM #108892
Closed

mrsharm mentioned this pull request Nov 8, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors #109567
Merged
4 tasks

mrsharm mentioned this pull request Nov 12, 2024
Fix an issue with sysconf returning the wrong last level cache values on Linux running on certain AMD Processors. #109749
Merged
3 tasks

mikelle-rogers pushed a commit to mikelle-rogers/runtime that referenced this pull request Dec 10, 2024
Fix an issue with the last level cache values on Linux running on cer…
418d065
…tain AMD Processors (dotnet#108492)

github-actionsBot locked and limited conversation to collaborators Dec 13, 2024

Uh oh!

Conversation

mrsharm commented Oct 2, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem Details

How To Check for the Issue

Solution

Performance Testing

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Maoni0 commented Oct 5, 2024

Uh oh!

janvorli commented Oct 8, 2024

Uh oh!

Maoni0 commented Oct 9, 2024

Uh oh!

janvorli commented Oct 9, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mrsharm commented Nov 5, 2024

How To Check for the Issue

Uh oh!

mrsharm commented Nov 12, 2024

Uh oh!

github-actionsBot commented Nov 12, 2024

Uh oh!

github-actionsBot commented Nov 12, 2024

Uh oh!

github-actionsBot commented Nov 12, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

mrsharm commented Oct 2, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem Details

How To Check for the Issue

Solution

Performance Testing

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Maoni0 commented Oct 5, 2024

Uh oh!

janvorli commented Oct 8, 2024

Uh oh!

Maoni0 commented Oct 9, 2024

Uh oh!

janvorli commented Oct 9, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mrsharm commented Nov 5, 2024

How To Check for the Issue

Uh oh!

mrsharm commented Nov 12, 2024

Uh oh!

github-actionsBot commented Nov 12, 2024

Uh oh!

github-actionsBot commented Nov 12, 2024

Uh oh!

github-actionsBot commented Nov 12, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

mrsharm commented Oct 2, 2024•
edited
Loading

janvorli commented Oct 9, 2024•
edited
Loading

mrsharm commented Oct 2, 2024•
edited
Loading

janvorli commented Oct 9, 2024•
edited
Loading

mrsharm commented Oct 2, 2024•
edited
Loading

janvorli commented Oct 9, 2024•
edited
Loading

mrsharm commented Oct 2, 2024•
edited
Loading