pytorch - ✅(Solved) Fix Greatly increased CPU memory use on aarch64 H100 node from torch 2.9.0 to torch 2.10.0 [1 pull requests, 3 comments, 2 participants]

pytorch2026-03-29 23:11:04

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

pytorch/pytorch#178726•Fetched 2026-04-08 01:48:25

View on GitHub

Comments

Participants

Timeline

Reactions

Author

alceballosa

Participants

alceballosa

katoue

Timeline (top)

mentioned ×27subscribed ×27labeled ×10commented ×3

Fix Action

Fix / Workaround

CPU: Architecture: aarch64 CPU op-mode(s): 64-bit Byte Order: Little Endian CPU(s): 288 On-line CPU(s) list: 0-287 Vendor ID: ARM Model name: Neoverse-V2 Model: 0 Thread(s) per core: 1 Core(s) per socket: 72 Socket(s): 4 Stepping: r0p0 Frequency boost: disabled CPU(s) scaling MHz: 100% CPU max MHz: 3465.0000 CPU min MHz: 81.0000 BogoMIPS: 2000.00 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh bti L1d cache: 18 MiB (288 instances) L1i cache: 18 MiB (288 instances) L2 cache: 288 MiB (288 instances) L3 cache: 456 MiB (4 instances) NUMA node(s): 36 NUMA node0 CPU(s): 0-71 NUMA node1 CPU(s): 72-143 NUMA node2 CPU(s): 144-215 NUMA node3 CPU(s): 216-287 NUMA node4 CPU(s): NUMA node5 CPU(s): NUMA node6 CPU(s): NUMA node7 CPU(s): NUMA node8 CPU(s): NUMA node9 CPU(s): NUMA node10 CPU(s): NUMA node11 CPU(s): NUMA node12 CPU(s): NUMA node13 CPU(s): NUMA node14 CPU(s): NUMA node15 CPU(s): NUMA node16 CPU(s): NUMA node17 CPU(s): NUMA node18 CPU(s): NUMA node19 CPU(s): NUMA node20 CPU(s): NUMA node21 CPU(s): NUMA node22 CPU(s): NUMA node23 CPU(s): NUMA node24 CPU(s): NUMA node25 CPU(s): NUMA node26 CPU(s): NUMA node27 CPU(s): NUMA node28 CPU(s): NUMA node29 CPU(s): NUMA node30 CPU(s): NUMA node31 CPU(s): NUMA node32 CPU(s): NUMA node33 CPU(s): NUMA node34 CPU(s): NUMA node35 CPU(s): Vulnerability Gather data sampling: Not affected Vulnerability Indirect target selection: Not affected Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Not affected Vulnerability Mds: Not affected Vulnerability Meltdown: Not affected Vulnerability Mmio stale data: Not affected Vulnerability Reg file data sampling: Not affected Vulnerability Retbleed: Not affected Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; __user pointer sanitization Vulnerability Spectre v2: Mitigation; CSV2, BHB Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected

PR fix notes

PR #178851: Fix 5x RAM regression in DataLoader on AArch64 by disabling mimalloc arena retention

Repository: pytorch/pytorch
Author: katoue
State: closed | merged: False
Link: https://github.com/pytorch/pytorch/pull/178851

Description (problem / solution / changelog)

Resolve #178726. From PyTorch 2.9 to 2.10, #164741 replaced glibc with mimalloc to increase memory allocation speed on AArch64. However, mimalloc retains freed memory in its arena for 10ms for caching purposes. As reported in #178726, this increases RAM usage by 5x and causes performance regressions.

Since DataLoader reads data sequentially, there is no benefit to arena caching, and setting mi_option_purge_delay to 0 resolves the issue by returning memory to the OS immediately.

Uses the official mimalloc API (mi_option_set_default) at third_party/mimalloc/include/mimalloc.h:432.

cc @ptrblck @msaroufim @eqy @jerryzh168 @tinglvv @nWEIdia @snadampal @milpuz01 @aditew01 @nikhil-arm @fadara01 @murste01 @malfet @alceballosa

Changed files

c10/core/impl/alloc_cpu.cpp (modified, +7/-0)

Code Example

import psutil; p = psutil.Process()
import torch
from torch.utils.data import DataLoader, Dataset

class DummyDataset(Dataset):
    def __len__(self): return 100
    def __getitem__(self, idx):
        return {
            'scan': torch.zeros(1, 400, 400, 300),
            'vessel_seg': torch.zeros(1, 400, 400, 300),
            'spacing': torch.tensor([1.0, 1.0, 1.0]),
        }

def collator(batch):
    return {
        'scan': torch.stack([b['scan'] for b in batch]),
        'vessel_seg': torch.stack([b['vessel_seg'] for b in batch]),
        'spacing': torch.stack([b['spacing'] for b in batch]),
    }

print(f'00 before loader:  {p.memory_info().rss/1e9:.2f}G')
dl = DataLoader(DummyDataset(), batch_size=2, num_workers=0, collate_fn=collator)
for i, batch in enumerate(dl):
    if i == 0:
        for k, v in batch.items():
            print(f'   {k}: shape={list(v.shape)} dtype={v.dtype} nbytes={v.nbytes/1e6:.1f}MB')
    del batch
    print(f'step {i:02d}:           {p.memory_info().rss/1e9:.2f}G')
    if i >= 19: break

---

00 before loader:  0.45G
   scan: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   vessel_seg: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   spacing: shape=[2, 3] dtype=torch.float32 nbytes=0.0MB
step 00:           1.24G
step 01:           1.19G
step 02:           1.20G
step 03:           1.23G
step 04:           1.24G
step 05:           1.19G
step 06:           1.21G
step 07:           1.21G
step 08:           1.23G
step 09:           1.24G
step 10:           1.19G
step 11:           1.22G
step 12:           1.20G
step 13:           1.25G
step 14:           1.18G
step 15:           1.22G
step 16:           1.25G
step 17:           1.17G
step 18:           1.19G
step 19:           1.18G

---

00 before loader:  0.45G
   scan: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   vessel_seg: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   spacing: shape=[2, 3] dtype=torch.float32 nbytes=0.0MB
step 00:           2.31G
step 01:           3.61G
step 02:           4.49G
step 03:           4.63G
step 04:           6.11G
step 05:           6.11G
step 06:           6.11G
step 07:           6.11G
step 08:           6.11G
step 09:           6.11G
step 10:           6.11G
step 11:           6.11G
step 12:           6.11G
step 13:           6.11G
step 14:           6.11G
step 15:           6.11G
step 16:           6.11G
step 17:           6.11G
step 18:           6.11G
step 19:           6.11G

RAW_BUFFERClick to expand / collapse

🐛 Describe the bug

Hi!

I recently upgraded to PyTorch 2.10.0 for 3D vision model training on an H100 node with aarch64 CPUs. I noticed increasingly frequent memory leaks. After tracking the leaks I found that compared to an environment using PyTorch 2.9.0, there is a huge increase in used CPU memory for tensors and likely some associated memory leaks. The following code reproduces the issue:

import psutil; p = psutil.Process()
import torch
from torch.utils.data import DataLoader, Dataset

class DummyDataset(Dataset):
    def __len__(self): return 100
    def __getitem__(self, idx):
        return {
            'scan': torch.zeros(1, 400, 400, 300),
            'vessel_seg': torch.zeros(1, 400, 400, 300),
            'spacing': torch.tensor([1.0, 1.0, 1.0]),
        }

def collator(batch):
    return {
        'scan': torch.stack([b['scan'] for b in batch]),
        'vessel_seg': torch.stack([b['vessel_seg'] for b in batch]),
        'spacing': torch.stack([b['spacing'] for b in batch]),
    }

print(f'00 before loader:  {p.memory_info().rss/1e9:.2f}G')
dl = DataLoader(DummyDataset(), batch_size=2, num_workers=0, collate_fn=collator)
for i, batch in enumerate(dl):
    if i == 0:
        for k, v in batch.items():
            print(f'   {k}: shape={list(v.shape)} dtype={v.dtype} nbytes={v.nbytes/1e6:.1f}MB')
    del batch
    print(f'step {i:02d}:           {p.memory_info().rss/1e9:.2f}G')
    if i >= 19: break

Results on 2.9.0:

00 before loader:  0.45G
   scan: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   vessel_seg: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   spacing: shape=[2, 3] dtype=torch.float32 nbytes=0.0MB
step 00:           1.24G
step 01:           1.19G
step 02:           1.20G
step 03:           1.23G
step 04:           1.24G
step 05:           1.19G
step 06:           1.21G
step 07:           1.21G
step 08:           1.23G
step 09:           1.24G
step 10:           1.19G
step 11:           1.22G
step 12:           1.20G
step 13:           1.25G
step 14:           1.18G
step 15:           1.22G
step 16:           1.25G
step 17:           1.17G
step 18:           1.19G
step 19:           1.18G

Results on 2.10.0:

00 before loader:  0.45G
   scan: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   vessel_seg: shape=[2, 1, 400, 400, 300] dtype=torch.float32 nbytes=384.0MB
   spacing: shape=[2, 3] dtype=torch.float32 nbytes=0.0MB
step 00:           2.31G
step 01:           3.61G
step 02:           4.49G
step 03:           4.63G
step 04:           6.11G
step 05:           6.11G
step 06:           6.11G
step 07:           6.11G
step 08:           6.11G
step 09:           6.11G
step 10:           6.11G
step 11:           6.11G
step 12:           6.11G
step 13:           6.11G
step 14:           6.11G
step 15:           6.11G
step 16:           6.11G
step 17:           6.11G
step 18:           6.11G
step 19:           6.11G

Env details with Torch 2.10.0 which results in increased memory usage, the 2.9.0 output is identical except for the torch version.

Any help you could provide would be immensely appreciated! I've been able to resume my work just fine with 2.9.0 but anything beyond that is unusable since I work with 3D arrays :(

Versions

Collecting environment information...
PyTorch version: 2.10.0+cu128
Is debug build: False
CUDA used to build PyTorch: 12.8
ROCM used to build PyTorch: N/A

OS: SUSE Linux Enterprise Server 15 SP6 (aarch64)
GCC version: (Spack GCC) 11.4.0
Clang version: Could not collect
CMake version: version 3.28.3
Libc version: glibc-2.38

Python version: 3.12.13 | packaged by conda-forge | (main, Mar  5 2026, 16:39:32) [GCC 14.3.0] (64-bit runtime)
Python platform: Linux-6.4.0-150600.23.53-64kb-aarch64-with-glibc2.38
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to:
GPU models and configuration: GPU 0: NVIDIA GH200 120GB
Nvidia driver version: 570.172.08
cuDNN version: Could not collect
Is XPU available: False
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True
Caching allocator config: N/A

CPU:
Architecture:                            aarch64
CPU op-mode(s):                          64-bit
Byte Order:                              Little Endian
CPU(s):                                  288
On-line CPU(s) list:                     0-287
Vendor ID:                               ARM
Model name:                              Neoverse-V2
Model:                                   0
Thread(s) per core:                      1
Core(s) per socket:                      72
Socket(s):                               4
Stepping:                                r0p0
Frequency boost:                         disabled
CPU(s) scaling MHz:                      100%
CPU max MHz:                             3465.0000
CPU min MHz:                             81.0000
BogoMIPS:                                2000.00
Flags:                                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh bti
L1d cache:                               18 MiB (288 instances)
L1i cache:                               18 MiB (288 instances)
L2 cache:                                288 MiB (288 instances)
L3 cache:                                456 MiB (4 instances)
NUMA node(s):                            36
NUMA node0 CPU(s):                       0-71
NUMA node1 CPU(s):                       72-143
NUMA node2 CPU(s):                       144-215
NUMA node3 CPU(s):                       216-287
NUMA node4 CPU(s):
NUMA node5 CPU(s):
NUMA node6 CPU(s):
NUMA node7 CPU(s):
NUMA node8 CPU(s):
NUMA node9 CPU(s):
NUMA node10 CPU(s):
NUMA node11 CPU(s):
NUMA node12 CPU(s):
NUMA node13 CPU(s):
NUMA node14 CPU(s):
NUMA node15 CPU(s):
NUMA node16 CPU(s):
NUMA node17 CPU(s):
NUMA node18 CPU(s):
NUMA node19 CPU(s):
NUMA node20 CPU(s):
NUMA node21 CPU(s):
NUMA node22 CPU(s):
NUMA node23 CPU(s):
NUMA node24 CPU(s):
NUMA node25 CPU(s):
NUMA node26 CPU(s):
NUMA node27 CPU(s):
NUMA node28 CPU(s):
NUMA node29 CPU(s):
NUMA node30 CPU(s):
NUMA node31 CPU(s):
NUMA node32 CPU(s):
NUMA node33 CPU(s):
NUMA node34 CPU(s):
NUMA node35 CPU(s):
Vulnerability Gather data sampling:      Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit:             Not affected
Vulnerability L1tf:                      Not affected
Vulnerability Mds:                       Not affected
Vulnerability Meltdown:                  Not affected
Vulnerability Mmio stale data:           Not affected
Vulnerability Reg file data sampling:    Not affected
Vulnerability Retbleed:                  Not affected
Vulnerability Spec rstack overflow:      Not affected
Vulnerability Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:                Mitigation; __user pointer sanitization
Vulnerability Spectre v2:                Mitigation; CSV2, BHB
Vulnerability Srbds:                     Not affected
Vulnerability Tsx async abort:           Not affected

Versions of relevant libraries:
[pip3] numpy==2.3.5
[pip3] nvidia-cublas-cu12==12.8.4.1
[pip3] nvidia-cuda-cupti-cu12==12.8.90
[pip3] nvidia-cuda-nvrtc-cu12==12.8.93
[pip3] nvidia-cuda-runtime-cu12==12.8.90
[pip3] nvidia-cudnn-cu12==9.10.2.21
[pip3] nvidia-cufft-cu12==11.3.3.83
[pip3] nvidia-curand-cu12==10.3.9.90
[pip3] nvidia-cusolver-cu12==11.7.3.90
[pip3] nvidia-cusparse-cu12==12.5.8.93
[pip3] nvidia-cusparselt-cu12==0.7.1
[pip3] nvidia-nccl-cu12==2.27.5
[pip3] nvidia-nvjitlink-cu12==12.8.93
[pip3] nvidia-nvtx-cu12==12.8.90
[pip3] torch==2.10.0+cu128
[pip3] torchaudio==2.11.0+cu128
[pip3] torchio==0.20.2
[pip3] torchvision==0.25.0+cu128
[pip3] triton==3.6.0
[conda] numpy                        2.3.5            pypi_0                pypi
[conda] nvidia-cublas-cu12           12.8.4.1         pypi_0                pypi
[conda] nvidia-cuda-cupti-cu12       12.8.90          pypi_0                pypi
[conda] nvidia-cuda-nvrtc-cu12       12.8.93          pypi_0                pypi
[conda] nvidia-cuda-runtime-cu12     12.8.90          pypi_0                pypi
[conda] nvidia-cudnn-cu12            9.10.2.21        pypi_0                pypi
[conda] nvidia-cufft-cu12            11.3.3.83        pypi_0                pypi
[conda] nvidia-curand-cu12           10.3.9.90        pypi_0                pypi
[conda] nvidia-cusolver-cu12         11.7.3.90        pypi_0                pypi
[conda] nvidia-cusparse-cu12         12.5.8.93        pypi_0                pypi
[conda] nvidia-cusparselt-cu12       0.7.1            pypi_0                pypi
[conda] nvidia-nccl-cu12             2.27.5           pypi_0                pypi
[conda] nvidia-nvjitlink-cu12        12.8.93          pypi_0                pypi
[conda] nvidia-nvtx-cu12             12.8.90          pypi_0                pypi
[conda] torch                        2.10.0+cu128     pypi_0                pypi
[conda] torchaudio                   2.11.0+cu128     pypi_0                pypi
[conda] torchio                      0.20.2           pypi_0                pypi
[conda] torchvision                  0.25.0+cu128     pypi_0                pypi
[conda] triton                       3.6.0            pypi_0                pypi

cc @jerryzh168

extent analysis

Fix Plan

The issue seems to be related to memory leaks in PyTorch 2.10.0. To fix this, we can try the following steps:

Downgrade PyTorch to 2.9.0: Since the issue is not present in PyTorch 2.9.0, downgrading to this version might resolve the problem.
Use del statement to delete tensors: Explicitly deleting tensors after use can help prevent memory leaks.
Use torch.cuda.empty_cache(): This function can be used to release cached memory on the GPU.

Here's an example of how you can modify your code to include these fixes:

import psutil; p = psutil.Process()
import torch
from torch.utils.data import DataLoader, Dataset

class DummyDataset(Dataset):
    def __len__(self): return 100
    def __getitem__(self, idx):
        return {
            'scan': torch.zeros(1, 400, 400, 300),
            'vessel_seg': torch.zeros(1, 400, 400, 300),
            'spacing': torch.tensor([1.0, 1.0, 1.0]),
        }

def collator(batch):
    return {
        'scan': torch.stack([b['scan'] for b in batch]),
        'vessel_seg': torch.stack([b['vessel_seg'] for b in batch]),
        'spacing': torch.stack([b['spacing'] for b in batch]),
    }

print(f'00 before loader:  {p.memory_info().rss/1e9:.2f}G')
dl = DataLoader(DummyDataset(), batch_size=2, num_workers=0, collate_fn=collator)
for i, batch in enumerate(dl):
    if i == 0:
        for k, v in batch.items():
            print(f'   {k}: shape={list(v.shape)} dtype={v.dtype} nbytes={v.nbytes/1e6:.1f}MB')
    del batch  # Explicitly delete the batch
    torch.cuda.empty_cache()  # Release cached memory on the GPU
    print(f'step {i:02d}:           {p.memory_info().rss/1e9:.2f}G')
    if i >= 19: break

Verification

To verify that the fix worked, you can run the modified code and check the memory usage. If the memory usage remains stable and does not increase over time, the fix has been successful.

Extra Tips

Make sure to regularly clean up tensors and other objects that are no longer needed to prevent memory leaks.
Consider using a memory profiler to identify memory leaks and optimize your code.
If you're working with large datasets, consider using a more efficient data loading mechanism, such as using DataLoader with

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#file not found #serialization error #model compatibility #GPU setup #memory leak

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Data

Security

Network

Code

UI/UX

Text

System

Multimedia

Protocol

API

Engineering

pytorch - ✅(Solved) Fix Greatly increased CPU memory use on aarch64 H100 node from torch 2.9.0 to torch 2.10.0 [1 pull requests, 3 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Fix Action

Fix / Workaround

PR fix notes

PR #178851: Fix 5x RAM regression in DataLoader on AArch64 by disabling mimalloc arena retention

Description (problem / solution / changelog)

Changed files

Code Example

🐛 Describe the bug

Versions

extent analysis

Fix Plan

Verification

Extra Tips

Still need to ship something?

TRENDING

pytorch - ✅(Solved) Fix Greatly increased CPU memory use on aarch64 H100 node from torch 2.9.0 to torch 2.10.0 [1 pull requests, 3 comments, 2 participants]

Recommended Tools

GitHub issue graph ai analysis

Fix Action

Fix / Workaround

PR fix notes

PR #178851: Fix 5x RAM regression in DataLoader on AArch64 by disabling mimalloc arena retention

Description (problem / solution / changelog)

Changed files

Code Example

🐛 Describe the bug

Versions

extent analysis

Fix Plan

Verification

Extra Tips

Still need to ship something?

RELATED_DISCOVERY

TRENDING