<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>sujet Why does CLFLUSHOPT improve remote CXL memory write performance? dans Software Tuning, Performance Optimization &amp; Platform Monitoring</title>
    <link>https://community.intel.com/t5/Software-Tuning-Performance/Why-does-CLFLUSHOPT-improve-remote-CXL-memory-write-performance/m-p/1750013#M8665</link>
    <description>&lt;P class=""&gt;&lt;SPAN&gt;Hello everyone and&amp;nbsp;&lt;A href="https://community.intel.com/t5/user/viewprofilepage/user-id/89357" target="_blank" rel="noopener"&gt;@McCalpinJohn&lt;/A&gt;&amp;nbsp;,&lt;/SPAN&gt;&lt;/P&gt;&lt;P class=""&gt;&lt;SPAN&gt;I'm currently experimenting with and optimizing the use of CXL memory, both locally and remotely across NUMA nodes.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;My test platform consists of:&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;SPAN&gt;2 × Intel(R) Xeon(R) Platinum 8468&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;2 NUMA nodes, 48 cores per socket&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;Hyper-Threading and Turbo Boost disabled&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;256 GB DDR memory attached to each NUMA node&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;1 × 256 GB CXL memory expansion card attached to NUMA node 0&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;The CXL device is configured as a CPU-less NUMA node (node 2)&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P class=""&gt;&lt;SPAN&gt;For this experiment, I do not use DDR memory. Instead, I force allocation from the CXL device while executing on the remote socket:&lt;/SPAN&gt;&lt;/P&gt;&lt;PRE&gt;&lt;SPAN&gt;numactl -N 1 -m 2 ./a.out&lt;/SPAN&gt;&lt;/PRE&gt;&lt;P&gt;&lt;SPAN&gt;And I always compile with:&lt;/SPAN&gt;&lt;/P&gt;&lt;PRE&gt;&lt;SPAN&gt;gcc -fopenmp -O3 cxl.memset.c&lt;/SPAN&gt;&lt;/PRE&gt;&lt;P&gt;&lt;SPAN&gt;&lt;BR /&gt;I started with a simple multi-threaded memset benchmark:&lt;/SPAN&gt;&lt;/P&gt;&lt;PRE&gt;#include &amp;lt;omp.h&amp;gt;
#include &amp;lt;stdio.h&amp;gt;
#include &amp;lt;stdlib.h&amp;gt;
#include &amp;lt;string.h&amp;gt;
#include &amp;lt;x86intrin.h&amp;gt;

int main() {

  char *mem;
  const size_t size = 1073741824;
  const size_t gran = 64;
  if (posix_memalign((void **)&amp;amp;mem, gran, size))
    return 1;
  memset(mem, 0, size);

  omp_set_num_threads(48);
  double st = omp_get_wtime();

  for (int r = 0; r &amp;lt;= 100; r++) {

#pragma omp parallel for
    for (size_t i = 0; i &amp;lt; size; i += gran) {
      memset(mem + i, (int)i, gran);
      asm volatile("clflushopt %0" : "+m"(*(volatile char *)(mem + i)));
    }
  }

  double elapsed = omp_get_wtime() - st;

  printf("elapsed: %.2fs\n", elapsed);
}&lt;/PRE&gt;&lt;P class=""&gt;&lt;SPAN&gt;The observation I do not yet understand is that adding&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;after each 64-byte write significantly improves performance.&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;SPAN&gt;Without&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;: 9.61 s&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;With&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;: 4.61 s&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P class=""&gt;&lt;SPAN&gt;Interestingly, this effect only appears when the CXL memory is accessed remotely from another NUMA node. When the same experiment is run locally,&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;provides little to no benefit. There is also no benefit when accessing remote DRAM. So it is unique to remote CXL memory.&lt;/SPAN&gt;&lt;/P&gt;&lt;P class=""&gt;&lt;SPAN&gt;I investigated this using&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;perf stat&lt;/SPAN&gt;&lt;SPAN&gt;, including Topdown metrics and lower-level groups such as:&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;SPAN&gt;tma_backend_bound_group&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;tma_memory_bound_group&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;tma_store_bound_group&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P class=""&gt;&lt;SPAN&gt;The counters mostly confirm what I already know (e.g., fewer store stalls, fewer cycles with outstanding RFOs, etc.), but they do not explain the underlying mechanism responsible for such a large speedup.&lt;/SPAN&gt;&lt;/P&gt;&lt;P class=""&gt;&lt;SPAN&gt;Has anyone encountered a similar phenomenon, particularly with remote CXL-attached memory? Is there a microarchitectural explanation for why aggressively flushing cache lines would improve throughput so dramatically in this scenario?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Thanks in advance for any insights.&lt;/SPAN&gt;&lt;/P&gt;</description>
    <pubDate>Wed, 03 Jun 2026 14:15:21 GMT</pubDate>
    <dc:creator>XiaoxiangWu</dc:creator>
    <dc:date>2026-06-03T14:15:21Z</dc:date>
    <item>
      <title>Why does CLFLUSHOPT improve remote CXL memory write performance?</title>
      <link>https://community.intel.com/t5/Software-Tuning-Performance/Why-does-CLFLUSHOPT-improve-remote-CXL-memory-write-performance/m-p/1750013#M8665</link>
      <description>&lt;P class=""&gt;&lt;SPAN&gt;Hello everyone and&amp;nbsp;&lt;A href="https://community.intel.com/t5/user/viewprofilepage/user-id/89357" target="_blank" rel="noopener"&gt;@McCalpinJohn&lt;/A&gt;&amp;nbsp;,&lt;/SPAN&gt;&lt;/P&gt;&lt;P class=""&gt;&lt;SPAN&gt;I'm currently experimenting with and optimizing the use of CXL memory, both locally and remotely across NUMA nodes.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;My test platform consists of:&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;SPAN&gt;2 × Intel(R) Xeon(R) Platinum 8468&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;2 NUMA nodes, 48 cores per socket&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;Hyper-Threading and Turbo Boost disabled&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;256 GB DDR memory attached to each NUMA node&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;1 × 256 GB CXL memory expansion card attached to NUMA node 0&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;The CXL device is configured as a CPU-less NUMA node (node 2)&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P class=""&gt;&lt;SPAN&gt;For this experiment, I do not use DDR memory. Instead, I force allocation from the CXL device while executing on the remote socket:&lt;/SPAN&gt;&lt;/P&gt;&lt;PRE&gt;&lt;SPAN&gt;numactl -N 1 -m 2 ./a.out&lt;/SPAN&gt;&lt;/PRE&gt;&lt;P&gt;&lt;SPAN&gt;And I always compile with:&lt;/SPAN&gt;&lt;/P&gt;&lt;PRE&gt;&lt;SPAN&gt;gcc -fopenmp -O3 cxl.memset.c&lt;/SPAN&gt;&lt;/PRE&gt;&lt;P&gt;&lt;SPAN&gt;&lt;BR /&gt;I started with a simple multi-threaded memset benchmark:&lt;/SPAN&gt;&lt;/P&gt;&lt;PRE&gt;#include &amp;lt;omp.h&amp;gt;
#include &amp;lt;stdio.h&amp;gt;
#include &amp;lt;stdlib.h&amp;gt;
#include &amp;lt;string.h&amp;gt;
#include &amp;lt;x86intrin.h&amp;gt;

int main() {

  char *mem;
  const size_t size = 1073741824;
  const size_t gran = 64;
  if (posix_memalign((void **)&amp;amp;mem, gran, size))
    return 1;
  memset(mem, 0, size);

  omp_set_num_threads(48);
  double st = omp_get_wtime();

  for (int r = 0; r &amp;lt;= 100; r++) {

#pragma omp parallel for
    for (size_t i = 0; i &amp;lt; size; i += gran) {
      memset(mem + i, (int)i, gran);
      asm volatile("clflushopt %0" : "+m"(*(volatile char *)(mem + i)));
    }
  }

  double elapsed = omp_get_wtime() - st;

  printf("elapsed: %.2fs\n", elapsed);
}&lt;/PRE&gt;&lt;P class=""&gt;&lt;SPAN&gt;The observation I do not yet understand is that adding&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;after each 64-byte write significantly improves performance.&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;SPAN&gt;Without&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;: 9.61 s&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;With&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;: 4.61 s&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P class=""&gt;&lt;SPAN&gt;Interestingly, this effect only appears when the CXL memory is accessed remotely from another NUMA node. When the same experiment is run locally,&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;clflushopt&lt;/SPAN&gt;&lt;SPAN&gt;&amp;nbsp;provides little to no benefit. There is also no benefit when accessing remote DRAM. So it is unique to remote CXL memory.&lt;/SPAN&gt;&lt;/P&gt;&lt;P class=""&gt;&lt;SPAN&gt;I investigated this using&amp;nbsp;&lt;/SPAN&gt;&lt;SPAN&gt;perf stat&lt;/SPAN&gt;&lt;SPAN&gt;, including Topdown metrics and lower-level groups such as:&lt;/SPAN&gt;&lt;/P&gt;&lt;UL&gt;&lt;LI&gt;&lt;SPAN&gt;tma_backend_bound_group&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;tma_memory_bound_group&lt;/SPAN&gt;&lt;/LI&gt;&lt;LI&gt;&lt;SPAN&gt;tma_store_bound_group&lt;/SPAN&gt;&lt;/LI&gt;&lt;/UL&gt;&lt;P class=""&gt;&lt;SPAN&gt;The counters mostly confirm what I already know (e.g., fewer store stalls, fewer cycles with outstanding RFOs, etc.), but they do not explain the underlying mechanism responsible for such a large speedup.&lt;/SPAN&gt;&lt;/P&gt;&lt;P class=""&gt;&lt;SPAN&gt;Has anyone encountered a similar phenomenon, particularly with remote CXL-attached memory? Is there a microarchitectural explanation for why aggressively flushing cache lines would improve throughput so dramatically in this scenario?&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Thanks in advance for any insights.&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 03 Jun 2026 14:15:21 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Tuning-Performance/Why-does-CLFLUSHOPT-improve-remote-CXL-memory-write-performance/m-p/1750013#M8665</guid>
      <dc:creator>XiaoxiangWu</dc:creator>
      <dc:date>2026-06-03T14:15:21Z</dc:date>
    </item>
  </channel>
</rss>

