GC picks wrong L3 cache size on Linux #76290

Closed
#108492
Closed
GC picks wrong L3 cache size on Linux#76290
#108492
Assignees
janvorli
Labels
area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
Milestone
10.0.0

Description

@smoogipoo
smoogipoo
opened on Sep 28, 2022

Description

In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.

System configuration:

  • AMD Ryzen 3950x

I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:

  • Linux:

    runtime/src/coreclr/gc/unix/gcenv.unix.cpp

    Lines 880 to 899 in 1955928

    size_t cacheLevel = 0;
    size_t cacheSize = 0;
    size_t size;
    #ifdef _SC_LEVEL1_DCACHE_SIZE
    size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE);
    UPDATE_CACHE_SIZE_AND_LEVEL(size, 1)
    #endif
    #ifdef _SC_LEVEL2_CACHE_SIZE
    size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE);
    UPDATE_CACHE_SIZE_AND_LEVEL(size, 2)
    #endif
    #ifdef _SC_LEVEL3_CACHE_SIZE
    size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE);
    UPDATE_CACHE_SIZE_AND_LEVEL(size, 3)
    #endif
    #ifdef _SC_LEVEL4_CACHE_SIZE
    size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE);
    UPDATE_CACHE_SIZE_AND_LEVEL(size, 4)
    #endif
  • Windows:

    runtime/src/coreclr/gc/windows/gcenv.windows.cpp

    Lines 405 to 435 in 1955928

    DWORD nEntries = 0;
    // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
    // if API not present or on failure.
    SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ;
    if (pslpi == NULL)
    {
    // GetLogicalProcessorInformation not supported or failed.
    goto Exit;
    }
    // Crack the information. Iterate through all the SLPI array entries for all processors in system.
    // Will return the greatest of all the processor cache sizes or zero
    {
    size_t last_cache_size = 0;
    for (DWORD i=0; i < nEntries; i++)
    {
    if (pslpi[i].Relationship == RelationCache)
    {
    if (last_cache_size < pslpi[i].Cache.Size)
    {
    last_cache_size = pslpi[i].Cache.Size;
    cache_level = pslpi[i].Cache.Level;
    }
    }
    }
    cache_size = last_cache_size;
    }

... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.

I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
image

This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.

On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935

... Which results in more reasonable values:

$ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

Reproduction Steps

I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest

It can be run on Windows and Linux.

Must be run with a multi-CCX CPU such as Ryzen 3950x.

Expected behavior

The cache size on Linux should be 16MiB.

Actual behavior

The cache size on Linux is 64MiB.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Metadata

Metadata

Assignees

Labels

area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
     blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

    Skip to content
    GC picks wrong L3 cache size on Linux #76290
    Closed
    #108492
    Closed
    GC picks wrong L3 cache size on Linux#76290
    #108492
    Assignees
    janvorli
    Labels
    area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
    Milestone
    10.0.0
    Description
    @smoogipoo
    smoogipoo
    opened on Sep 28, 2022
    Description
    In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.
    System configuration:
    • AMD Ryzen 3950x
    I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:
    • Linux: 
      runtime/src/coreclr/gc/unix/gcenv.unix.cpp
      
Lines 880 to 899
in
1955928
      size_t cacheLevel = 0; 
      size_t cacheSize = 0; 
      size_t size; 
       #ifdef _SC_LEVEL1_DCACHE_SIZE 
       size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE); 
      UPDATE_CACHE_SIZE_AND_LEVEL(size, 1) 
       #endif
       #ifdef _SC_LEVEL2_CACHE_SIZE 
       size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE); 
      UPDATE_CACHE_SIZE_AND_LEVEL(size, 2) 
       #endif
       #ifdef _SC_LEVEL3_CACHE_SIZE 
       size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE); 
      UPDATE_CACHE_SIZE_AND_LEVEL(size, 3) 
       #endif
       #ifdef _SC_LEVEL4_CACHE_SIZE 
       size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE); 
      UPDATE_CACHE_SIZE_AND_LEVEL(size, 4) 
       #endif
    • Windows: 
      runtime/src/coreclr/gc/windows/gcenv.windows.cpp
      
Lines 405 to 435
in
1955928
      DWORD nEntries = 0; 
      // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
      // if API not present or on failure.
      SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ; 
      if (pslpi == NULL) 
       { 
      // GetLogicalProcessorInformation not supported or failed.
      goto Exit; 
       } 
      // Crack the information. Iterate through all the SLPI array entries for all processors in system.
      // Will return the greatest of all the processor cache sizes or zero
       { 
      size_t last_cache_size = 0; 
      for (DWORD i=0; i < nEntries; i++) 
       { 
      if (pslpi[i].Relationship == RelationCache) 
       { 
      if (last_cache_size < pslpi[i].Cache.Size) 
       { 
       last_cache_size = pslpi[i].Cache.Size; 
       cache_level = pslpi[i].Cache.Level; 
       } 
       } 
       } 
       cache_size = last_cache_size; 
       } 
    ... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.
    I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
    image
    This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.
    On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935
    ... Which results in more reasonable values:
    $ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

    Reproduction Steps
    I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest
    It can be run on Windows and Linux.
    Must be run with a multi-CCX CPU such as Ryzen 3950x.
    Expected behavior
    The cache size on Linux should be 16MiB.
    Actual behavior
    The cache size on Linux is 64MiB.
    Regression?
    No response
    Known Workarounds
    No response
    Configuration
    No response
    Other information
    No response
    Metadata
    Metadata
    Assignees
    Labels
    area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
    Type
    No type
    Projects
    No projects
      Milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

      Skip to content
      GC picks wrong L3 cache size on Linux #76290
      Closed
      #108492
      Closed
      GC picks wrong L3 cache size on Linux#76290
      #108492
      Assignees
      janvorli
      Labels
      area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
      Milestone
      10.0.0
      Description
      @smoogipoo
      smoogipoo
      opened on Sep 28, 2022
      Description
      In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.
      System configuration:
      • AMD Ryzen 3950x
      I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:
      • Linux: 
        runtime/src/coreclr/gc/unix/gcenv.unix.cpp
        
Lines 880 to 899
in
1955928
        size_t cacheLevel = 0; 
        size_t cacheSize = 0; 
        size_t size; 
         #ifdef _SC_LEVEL1_DCACHE_SIZE 
         size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE); 
        UPDATE_CACHE_SIZE_AND_LEVEL(size, 1) 
         #endif
         #ifdef _SC_LEVEL2_CACHE_SIZE 
         size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE); 
        UPDATE_CACHE_SIZE_AND_LEVEL(size, 2) 
         #endif
         #ifdef _SC_LEVEL3_CACHE_SIZE 
         size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE); 
        UPDATE_CACHE_SIZE_AND_LEVEL(size, 3) 
         #endif
         #ifdef _SC_LEVEL4_CACHE_SIZE 
         size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE); 
        UPDATE_CACHE_SIZE_AND_LEVEL(size, 4) 
         #endif
      • Windows: 
        runtime/src/coreclr/gc/windows/gcenv.windows.cpp
        
Lines 405 to 435
in
1955928
        DWORD nEntries = 0; 
        // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
        // if API not present or on failure.
        SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ; 
        if (pslpi == NULL) 
         { 
        // GetLogicalProcessorInformation not supported or failed.
        goto Exit; 
         } 
        // Crack the information. Iterate through all the SLPI array entries for all processors in system.
        // Will return the greatest of all the processor cache sizes or zero
         { 
        size_t last_cache_size = 0; 
        for (DWORD i=0; i < nEntries; i++) 
         { 
        if (pslpi[i].Relationship == RelationCache) 
         { 
        if (last_cache_size < pslpi[i].Cache.Size) 
         { 
         last_cache_size = pslpi[i].Cache.Size; 
         cache_level = pslpi[i].Cache.Level; 
         } 
         } 
         } 
         cache_size = last_cache_size; 
         } 
      ... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.
      I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
      image
      This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.
      On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935
      ... Which results in more reasonable values:
      $ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

      Reproduction Steps
      I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest
      It can be run on Windows and Linux.
      Must be run with a multi-CCX CPU such as Ryzen 3950x.
      Expected behavior
      The cache size on Linux should be 16MiB.
      Actual behavior
      The cache size on Linux is 64MiB.
      Regression?
      No response
      Known Workarounds
      No response
      Configuration
      No response
      Other information
      No response
      Metadata
      Metadata
      Assignees
      Labels
      area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
      Type
      No type
      Projects
      No projects
        Milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

        Skip to content
        GC picks wrong L3 cache size on Linux #76290
        Closed
        #108492
        Closed
        GC picks wrong L3 cache size on Linux#76290
        #108492
        Assignees
        janvorli
        Labels
        area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
        Milestone
        10.0.0
        Description
        @smoogipoo
        smoogipoo
        opened on Sep 28, 2022
        Description
        In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.
        System configuration:
        • AMD Ryzen 3950x
        I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:
        • Linux: 
          runtime/src/coreclr/gc/unix/gcenv.unix.cpp
          
Lines 880 to 899
in
1955928
          size_t cacheLevel = 0; 
          size_t cacheSize = 0; 
          size_t size; 
           #ifdef _SC_LEVEL1_DCACHE_SIZE 
           size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE); 
          UPDATE_CACHE_SIZE_AND_LEVEL(size, 1) 
           #endif
           #ifdef _SC_LEVEL2_CACHE_SIZE 
           size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE); 
          UPDATE_CACHE_SIZE_AND_LEVEL(size, 2) 
           #endif
           #ifdef _SC_LEVEL3_CACHE_SIZE 
           size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE); 
          UPDATE_CACHE_SIZE_AND_LEVEL(size, 3) 
           #endif
           #ifdef _SC_LEVEL4_CACHE_SIZE 
           size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE); 
          UPDATE_CACHE_SIZE_AND_LEVEL(size, 4) 
           #endif
        • Windows: 
          runtime/src/coreclr/gc/windows/gcenv.windows.cpp
          
Lines 405 to 435
in
1955928
          DWORD nEntries = 0; 
          // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
          // if API not present or on failure.
          SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ; 
          if (pslpi == NULL) 
           { 
          // GetLogicalProcessorInformation not supported or failed.
          goto Exit; 
           } 
          // Crack the information. Iterate through all the SLPI array entries for all processors in system.
          // Will return the greatest of all the processor cache sizes or zero
           { 
          size_t last_cache_size = 0; 
          for (DWORD i=0; i < nEntries; i++) 
           { 
          if (pslpi[i].Relationship == RelationCache) 
           { 
          if (last_cache_size < pslpi[i].Cache.Size) 
           { 
           last_cache_size = pslpi[i].Cache.Size; 
           cache_level = pslpi[i].Cache.Level; 
           } 
           } 
           } 
           cache_size = last_cache_size; 
           } 
        ... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.
        I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
        image
        This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.
        On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935
        ... Which results in more reasonable values:
        $ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

        Reproduction Steps
        I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest
        It can be run on Windows and Linux.
        Must be run with a multi-CCX CPU such as Ryzen 3950x.
        Expected behavior
        The cache size on Linux should be 16MiB.
        Actual behavior
        The cache size on Linux is 64MiB.
        Regression?
        No response
        Known Workarounds
        No response
        Configuration
        No response
        Other information
        No response
        Metadata
        Metadata
        Assignees
        Labels
        area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
        Type
        No type
        Projects
        No projects
          Milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

          Skip to content
          GC picks wrong L3 cache size on Linux #76290
          Closed
          #108492
          Closed
          GC picks wrong L3 cache size on Linux#76290
          #108492
          Assignees
          janvorli
          Labels
          area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
          Milestone
          10.0.0
          Description
          @smoogipoo
          smoogipoo
          opened on Sep 28, 2022
          Description
          In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.
          System configuration:
          • AMD Ryzen 3950x
          I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:
          • Linux: 
            runtime/src/coreclr/gc/unix/gcenv.unix.cpp
            
Lines 880 to 899
in
1955928
            size_t cacheLevel = 0; 
            size_t cacheSize = 0; 
            size_t size; 
             #ifdef _SC_LEVEL1_DCACHE_SIZE 
             size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE); 
            UPDATE_CACHE_SIZE_AND_LEVEL(size, 1) 
             #endif
             #ifdef _SC_LEVEL2_CACHE_SIZE 
             size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE); 
            UPDATE_CACHE_SIZE_AND_LEVEL(size, 2) 
             #endif
             #ifdef _SC_LEVEL3_CACHE_SIZE 
             size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE); 
            UPDATE_CACHE_SIZE_AND_LEVEL(size, 3) 
             #endif
             #ifdef _SC_LEVEL4_CACHE_SIZE 
             size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE); 
            UPDATE_CACHE_SIZE_AND_LEVEL(size, 4) 
             #endif
          • Windows: 
            runtime/src/coreclr/gc/windows/gcenv.windows.cpp
            
Lines 405 to 435
in
1955928
            DWORD nEntries = 0; 
            // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
            // if API not present or on failure.
            SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ; 
            if (pslpi == NULL) 
             { 
            // GetLogicalProcessorInformation not supported or failed.
            goto Exit; 
             } 
            // Crack the information. Iterate through all the SLPI array entries for all processors in system.
            // Will return the greatest of all the processor cache sizes or zero
             { 
            size_t last_cache_size = 0; 
            for (DWORD i=0; i < nEntries; i++) 
             { 
            if (pslpi[i].Relationship == RelationCache) 
             { 
            if (last_cache_size < pslpi[i].Cache.Size) 
             { 
             last_cache_size = pslpi[i].Cache.Size; 
             cache_level = pslpi[i].Cache.Level; 
             } 
             } 
             } 
             cache_size = last_cache_size; 
             } 
          ... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.
          I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
          image
          This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.
          On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935
          ... Which results in more reasonable values:
          $ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

          Reproduction Steps
          I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest
          It can be run on Windows and Linux.
          Must be run with a multi-CCX CPU such as Ryzen 3950x.
          Expected behavior
          The cache size on Linux should be 16MiB.
          Actual behavior
          The cache size on Linux is 64MiB.
          Regression?
          No response
          Known Workarounds
          No response
          Configuration
          No response
          Other information
          No response
          Metadata
          Metadata
          Assignees
          Labels
          area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
          Type
          No type
          Projects
          No projects
            Milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

            Skip to content
            GC picks wrong L3 cache size on Linux #76290
            Closed
            #108492
            Closed
            GC picks wrong L3 cache size on Linux#76290
            #108492
            Assignees
            janvorli
            Labels
            area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
            Milestone
            10.0.0
            Description
            @smoogipoo
            smoogipoo
            opened on Sep 28, 2022
            Description
            In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.
            System configuration:
            • AMD Ryzen 3950x
            I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:
            • Linux: 
              runtime/src/coreclr/gc/unix/gcenv.unix.cpp
              
Lines 880 to 899
in
1955928
              size_t cacheLevel = 0; 
              size_t cacheSize = 0; 
              size_t size; 
               #ifdef _SC_LEVEL1_DCACHE_SIZE 
               size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE); 
              UPDATE_CACHE_SIZE_AND_LEVEL(size, 1) 
               #endif
               #ifdef _SC_LEVEL2_CACHE_SIZE 
               size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE); 
              UPDATE_CACHE_SIZE_AND_LEVEL(size, 2) 
               #endif
               #ifdef _SC_LEVEL3_CACHE_SIZE 
               size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE); 
              UPDATE_CACHE_SIZE_AND_LEVEL(size, 3) 
               #endif
               #ifdef _SC_LEVEL4_CACHE_SIZE 
               size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE); 
              UPDATE_CACHE_SIZE_AND_LEVEL(size, 4) 
               #endif
            • Windows: 
              runtime/src/coreclr/gc/windows/gcenv.windows.cpp
              
Lines 405 to 435
in
1955928
              DWORD nEntries = 0; 
              // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
              // if API not present or on failure.
              SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ; 
              if (pslpi == NULL) 
               { 
              // GetLogicalProcessorInformation not supported or failed.
              goto Exit; 
               } 
              // Crack the information. Iterate through all the SLPI array entries for all processors in system.
              // Will return the greatest of all the processor cache sizes or zero
               { 
              size_t last_cache_size = 0; 
              for (DWORD i=0; i < nEntries; i++) 
               { 
              if (pslpi[i].Relationship == RelationCache) 
               { 
              if (last_cache_size < pslpi[i].Cache.Size) 
               { 
               last_cache_size = pslpi[i].Cache.Size; 
               cache_level = pslpi[i].Cache.Level; 
               } 
               } 
               } 
               cache_size = last_cache_size; 
               } 
            ... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.
            I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
            image
            This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.
            On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935
            ... Which results in more reasonable values:
            $ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

            Reproduction Steps
            I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest
            It can be run on Windows and Linux.
            Must be run with a multi-CCX CPU such as Ryzen 3950x.
            Expected behavior
            The cache size on Linux should be 16MiB.
            Actual behavior
            The cache size on Linux is 64MiB.
            Regression?
            No response
            Known Workarounds
            No response
            Configuration
            No response
            Other information
            No response
            Metadata
            Metadata
            Assignees
            Labels
            area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
            Type
            No type
            Projects
            No projects
              Milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

              Skip to content
              GC picks wrong L3 cache size on Linux #76290
              Closed
              #108492
              Closed
              GC picks wrong L3 cache size on Linux#76290
              #108492
              Assignees
              janvorli
              Labels
              area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
              Milestone
              10.0.0
              Description
              @smoogipoo
              smoogipoo
              opened on Sep 28, 2022
              Description
              In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.
              System configuration:
              • AMD Ryzen 3950x
              I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:
              • Linux: 
                runtime/src/coreclr/gc/unix/gcenv.unix.cpp
                
Lines 880 to 899
in
1955928
                size_t cacheLevel = 0; 
                size_t cacheSize = 0; 
                size_t size; 
                 #ifdef _SC_LEVEL1_DCACHE_SIZE 
                 size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE); 
                UPDATE_CACHE_SIZE_AND_LEVEL(size, 1) 
                 #endif
                 #ifdef _SC_LEVEL2_CACHE_SIZE 
                 size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE); 
                UPDATE_CACHE_SIZE_AND_LEVEL(size, 2) 
                 #endif
                 #ifdef _SC_LEVEL3_CACHE_SIZE 
                 size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE); 
                UPDATE_CACHE_SIZE_AND_LEVEL(size, 3) 
                 #endif
                 #ifdef _SC_LEVEL4_CACHE_SIZE 
                 size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE); 
                UPDATE_CACHE_SIZE_AND_LEVEL(size, 4) 
                 #endif
              • Windows: 
                runtime/src/coreclr/gc/windows/gcenv.windows.cpp
                
Lines 405 to 435
in
1955928
                DWORD nEntries = 0; 
                // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
                // if API not present or on failure.
                SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ; 
                if (pslpi == NULL) 
                 { 
                // GetLogicalProcessorInformation not supported or failed.
                goto Exit; 
                 } 
                // Crack the information. Iterate through all the SLPI array entries for all processors in system.
                // Will return the greatest of all the processor cache sizes or zero
                 { 
                size_t last_cache_size = 0; 
                for (DWORD i=0; i < nEntries; i++) 
                 { 
                if (pslpi[i].Relationship == RelationCache) 
                 { 
                if (last_cache_size < pslpi[i].Cache.Size) 
                 { 
                 last_cache_size = pslpi[i].Cache.Size; 
                 cache_level = pslpi[i].Cache.Level; 
                 } 
                 } 
                 } 
                 cache_size = last_cache_size; 
                 } 
              ... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.
              I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
              image
              This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.
              On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935
              ... Which results in more reasonable values:
              $ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

              Reproduction Steps
              I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest
              It can be run on Windows and Linux.
              Must be run with a multi-CCX CPU such as Ryzen 3950x.
              Expected behavior
              The cache size on Linux should be 16MiB.
              Actual behavior
              The cache size on Linux is 64MiB.
              Regression?
              No response
              Known Workarounds
              No response
              Configuration
              No response
              Other information
              No response
              Metadata
              Metadata
              Assignees
              Labels
              area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
              Type
              No type
              Projects
              No projects
                Milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions
                
, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

                Skip to content
                GC picks wrong L3 cache size on Linux #76290
                Closed
                #108492
                Closed
                GC picks wrong L3 cache size on Linux#76290
                #108492
                Assignees
                janvorli
                Labels
                area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
                Milestone
                10.0.0
                Description
                @smoogipoo
                smoogipoo
                opened on Sep 28, 2022
                Description
                In #48937 it was found that my gen0 budget was 32MiB. Investigating this further, I believe it may even be as high as 64MiB which causes the erratic Gen0 collection times I'm seeing.
                System configuration:
                • AMD Ryzen 3950x
                I wrote a simple app following the implementations that the GC uses on x86 (as far as I can tell) for both Linux and Windows:
                • Linux: 
                  runtime/src/coreclr/gc/unix/gcenv.unix.cpp
                  
Lines 880 to 899
in
1955928
                  size_t cacheLevel = 0; 
                  size_t cacheSize = 0; 
                  size_t size; 
                   #ifdef _SC_LEVEL1_DCACHE_SIZE 
                   size = ( size_t) sysconf(_SC_LEVEL1_DCACHE_SIZE); 
                  UPDATE_CACHE_SIZE_AND_LEVEL(size, 1) 
                   #endif
                   #ifdef _SC_LEVEL2_CACHE_SIZE 
                   size = ( size_t) sysconf(_SC_LEVEL2_CACHE_SIZE); 
                  UPDATE_CACHE_SIZE_AND_LEVEL(size, 2) 
                   #endif
                   #ifdef _SC_LEVEL3_CACHE_SIZE 
                   size = ( size_t) sysconf(_SC_LEVEL3_CACHE_SIZE); 
                  UPDATE_CACHE_SIZE_AND_LEVEL(size, 3) 
                   #endif
                   #ifdef _SC_LEVEL4_CACHE_SIZE 
                   size = ( size_t) sysconf(_SC_LEVEL4_CACHE_SIZE); 
                  UPDATE_CACHE_SIZE_AND_LEVEL(size, 4) 
                   #endif
                • Windows: 
                  runtime/src/coreclr/gc/windows/gcenv.windows.cpp
                  
Lines 405 to 435
in
1955928
                  DWORD nEntries = 0; 
                  // Try to use GetLogicalProcessorInformation API and get a valid pointer to the SLPI array if successful. Returns NULL
                  // if API not present or on failure.
                  SYSTEM_LOGICAL_PROCESSOR_INFORMATION *pslpi = GetLPI(&nEntries) ; 
                  if (pslpi == NULL) 
                   { 
                  // GetLogicalProcessorInformation not supported or failed.
                  goto Exit; 
                   } 
                  // Crack the information. Iterate through all the SLPI array entries for all processors in system.
                  // Will return the greatest of all the processor cache sizes or zero
                   { 
                  size_t last_cache_size = 0; 
                  for (DWORD i=0; i < nEntries; i++) 
                   { 
                  if (pslpi[i].Relationship == RelationCache) 
                   { 
                  if (last_cache_size < pslpi[i].Cache.Size) 
                   { 
                   last_cache_size = pslpi[i].Cache.Size; 
                   cache_level = pslpi[i].Cache.Level; 
                   } 
                   } 
                   } 
                   cache_size = last_cache_size; 
                   } 
                ... And found that on Windows it outputs a cache size of 16MiB and on Linux of 64MiB.
                I believe the 64MiB value to be incorrectly chosen for this system given the CPU topology:
                image
                This makes sense, since _SC_LEVEL3_CACHE_SIZE returns the total L3 size.
                On other platforms, the GC queries /sys/devices/system/cpu/cpu0/cache/index*/size to determine the cache size: https://github.com/filipnavara/runtime/blob/1955928833e178392f3a40ac1509f0d4a6ca7632/src/coreclr/gc/unix/gcenv.unix.cpp#L901-L935
                ... Which results in more reasonable values:
                $ cat /sys/devices/system/cpu/cpu0/cache/index0/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index1/size
32K
$ cat /sys/devices/system/cpu/cpu0/cache/index2/size
512K
$ cat /sys/devices/system/cpu/cpu0/cache/index3/size
16384K

                Reproduction Steps
                I'm not sure how to extract the Gen0 budget from the GC, so I wrote an app that uses the same method as the GC to determine cache size: https://github.com/smoogipoo/CacheSizeTest
                It can be run on Windows and Linux.
                Must be run with a multi-CCX CPU such as Ryzen 3950x.
                Expected behavior
                The cache size on Linux should be 16MiB.
                Actual behavior
                The cache size on Linux is 64MiB.
                Regression?
                No response
                Known Workarounds
                No response
                Configuration
                No response
                Other information
                No response
                Metadata
                Metadata
                Assignees
                Labels
                area-GC-coreclrin-prThere is an active PR which will close this issue when it is merged
                Type
                No type
                Projects
                No projects
                  Milestone
                  Relationships
                  None yet
                  Development
                  No branches or pull requests
                  Issue actions