Bug 2459104

Summary: Large memory spike with small (10 mb) scp transfer
Product: [Fedora] Fedora Reporter: Saurabh Rawat <saurabh.rawat>
Component: kernelAssignee: Charles Haithcock <chaithco>
Status: ASSIGNED --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 44CC: acaringi, adscvr, airlied, chaithco, hans, hpa, jforbes, kernel-maint, linville, masami256, mchehab, nickolasjcarr, ptalbert, steved, suraj.ghimire7
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg log
none
memory watch log none

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.
Comment 4 Charles Haithcock 2026-08-04 15:00:00 UTC 
Hey Saurabh,

Thanks for reporting this. It looks like the upstream bug has progressed to being resolved with a current upstream kernel release based on the 7.0.14 kernel and above. Fedora 44 has access to the 7.1.5 kernel via 7.1.5-201 kernel packages. Are you able to update the kernel and see if the issue is reproduced? Likewise, disabling TSO seemed to workaround the issue in the upstream report (https://bugzilla.kernel.org/show_bug.cgi?id=221092#c14) are you able to test with that as well?

The reason I ask for the additional testing with TSO disabled is because the memory consumption reported here is not brought up in the upstream report. I am not exactly convinced the upstream bug is a match for the reported bug here (though it is entirely possible the issue is the same but has different symptoms under different circumstances). So the request to test with TSO disabled is to help support the idea the two reports are for the same issue.

Thank you!
Comment 5 Saurabh Rawat 2026-08-05 07:09:51 UTC 
Hi Charles,

Thanks for taking a look.
Unfortunately I am on alma 10 and back to using this system as my primary device, so not possible for me to test Fedora now.
Sorry about that.

I believe it was the same issue though: https://github.com/basecamp/omarchy/issues/5827#issuecomment-4714931911
John has reported it to be fixed.

Thanks