Bug 2459104 - Large memory spike with small (10 mb) scp transfer
Summary: Large memory spike with small (10 mb) scp transfer
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 44
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Justin M. Forbes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-04-17 03:51 UTC by Saurabh Rawat
Modified: 2026-04-28 13:13 UTC (History)
14 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg log (146.59 KB, text/plain)
2026-04-17 03:52 UTC, Saurabh Rawat
no flags Details
memory watch log (9.21 KB, text/plain)
2026-04-17 03:53 UTC, Saurabh Rawat
no flags Details

Description Saurabh Rawat 2026-04-17 03:51:45 UTC
1. Please describe the problem:
I am seeing a large memory spike (19-21gb) when trying to scp a small file 10mb.

2. What is the Version-Release number of the kernel:
6.19.12-300.fc44.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
I have not been able to test since when this problem is present.
I know it's present in the newer linux kernel being used by ubuntu 26.04

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Yes, consistently.
Create a file:
dd if=/dev/urandom of=/tmp/test10m bs=1M count=10
Transfer it:
scp /tmp/test10m any_host:/tmp/test10m

it might take 2-3 transfers for it to trigger.

rsync shows the same behaviour, nc doesn't show it.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
I did not try it.

6. Are you running any modules that not shipped with directly Fedora's kernel?:
No, but I am force probing xe driver instead of i915

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

mem log captured using:

```
while true; do
    echo "=== $(date +%T) ===" >> /tmp/memwatch.txt
    grep -E 'MemTotal|MemFree|SwapFree|Slab|SReclaimable|SUnreclaim' /proc/meminfo >> /tmp/memwatch.txt
    sleep 1
done
```

07:55:23  MemFree: 14.8GB   SUnreclaim: 356MB    ← normal
07:55:24  MemFree: 10.7GB   SUnreclaim: 4.4GB    ← spike starts
07:55:25  MemFree: 5.5GB    SUnreclaim: 9.6GB
07:55:26  MemFree: 0.4GB    SUnreclaim: 14.7GB   ← nearly OOM!
07:55:27  MemFree: 0.5GB    SUnreclaim: 19.2GB   ← swap kicks in
07:55:28  MemFree: 1.7GB    SUnreclaim: 21.2GB   ← peak
07:55:29  MemFree: 10.5GB   SUnreclaim: 12GB     ← collapsing
07:55:30  MemFree: 19.2GB   SUnreclaim: 3.3GB
07:55:31  MemFree: 22GB     SUnreclaim: 343MB    ← back to normal


Reproducible: Always

Comment 1 Saurabh Rawat 2026-04-17 03:52:46 UTC
Created attachment 2137422 [details]
dmesg log

Comment 2 Saurabh Rawat 2026-04-17 03:53:23 UTC
Created attachment 2137423 [details]
memory watch log

Comment 3 Saurabh Rawat 2026-04-28 13:13:50 UTC
Reported here https://bugzilla.kernel.org/show_bug.cgi?id=221092
as an intel be201 issue.


Note You need to log in before you can comment on or make changes to this bug.