Pasta consumes high load CPU

[yuki]

Issue Description

Podman rootless container with Qbitorrent image, and Pasta network, the Pasta process consumes high load of CPU (higher than 90%).

It only occurs when downloading in high speed.

Steps to reproduce the issue

Steps to reproduce the issue:

1. Create a rootless qbitorrent container

podman run --rm --name qbit-test -p 8080:8080 -v ./Descargas:/downloads lscr.io/linuxserver/qbittorrent:latest

2. Start downloading 1-2 torrents with lots of seeders
3. Open htop/top and see how passt.avx2 process consumes CPU.

Describe the results you received

ps aux | grep -i pasta
/usr/bin/pasta --config-net -t 8080-8080:8080-8080 --dns-forward 169.254.1.1 -u none -T none -U none --no-map-gw --quiet --netns /run/user/1000/netns/netns-474aff30-f3e2-6ae9-08b7-b7e1ab6fc549 --map-guest-addr 169.254.1.2

In top:

    PID   USUARIO   PR  NI    VIRT          RES    SHR S  %CPU  %MEM     HORA+ ORDEN                                                                                                                       
 171957       yuki  20   0  194008  36036   1384 R     96,8       0,2       2:43.08 passt.avx2 

Describe the results you expected

I assume that the pasta process should be not so high.

podman info output

Podman info:


host:
  arch: amd64
  buildahVersion: 1.43.2
  cgroupControllers:
  - memory
  - pids
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-1:2.2.1-1
    path: /usr/bin/conmon
    version: 'conmon version 2.2.1, commit: c8cc2c4db27531bd4e084ce7857f73cd21ee639d'
  cpuUtilization:
    idlePercent: 90.37
    systemPercent: 3.37
    userPercent: 6.26
  cpus: 6
  databaseBackend: sqlite
  distribution:
    distribution: arch
    version: unknown
  eventLogger: journald
  freeLocks: 2028
  hostname: archy
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 7.0.12-zen1-1-zen
  linkmode: dynamic
  logDriver: journald
  memFree: 1953529856
  memTotal: 16667205632
  networkBackend: netavark
  networkBackendInfo:
    backend: netavark
    defaultNetwork: podman
    dns:
      package: aardvark-dns-1.17.1-1
      path: /usr/lib/podman/aardvark-dns
      version: aardvark-dns 1.17.1
    package: netavark-1.17.2-2
    path: /usr/lib/podman/netavark
    version: netavark 1.17.2
  ociRuntime:
    name: crun
    package: crun-1.28-1
    path: /usr/bin/crun
    version: |-
      crun version 1.28-dirty
      commit: 54f16ffbefcd022bf032af768b5c5ce075c18bfc
      rundir: /run/user/1000/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +JSON_C
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-2026_06_11.a9c61ff-1
    version: |
      pasta 2026_06_11.a9c61ff
      Copyright Red Hat
      GNU General Public License, version 2 or later
        <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  rootlessNetworkCmd: pasta
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /etc/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 1850621952
  swapTotal: 4294963200
  uptime: 62h 8m 7.00s (Approximately 2.58 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
store:
  configFile: /home/yuki/.config/containers/storage.conf
  containerStore:
    number: 9
    paused: 0
    running: 8
    stopped: 1
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/yuki/.local/share/containers/storage
  graphRootAllocated: 822705717248
  graphRootUsed: 71725723648
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Supports shifting: "false"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 9
  runRoot: /run/user/1000/containers
  transientStore: false
  volumePath: /home/yuki/.local/share/containers/storage/volumes
version:
  APIVersion: 5.8.3
  Built: 1781291692
  BuiltTime: Fri Jun 12 21:14:52 2026
  GitCommit: 93dbfd0d86ee57f8f91801f61ce57dd880a4725f
  GoVersion: go1.26.4-X:nodwarf5
  Os: linux
  OsArch: linux/amd64
  Version: 5.8.3

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

[yuki]

I can replicate using a container with iperf3. Pasta goes up to 90% and then down a bit.

podman run -p 5201:5201 -it openeuler/iperf /bin/bash   

Welcome to 7.0.12-zen1-1-zen

System information as of time: 	Sat Jun 20 08:25:10 UTC 2026
System load: 	0.38
Memory used: 	16.3%
Swap used: 	30.0%
Usage On: 	10%
Users online: 	0


[root@df0cf3308e2f /]# iperf3 -s

In other terminal in the host computer:

iperf3 -c localhost -t 0
Connecting to host localhost, port 5201
[  5] local ::1 port 55706 connected to ::1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.92 GBytes  59.4 Gbits/sec    0   2.00 MBytes       
[  5]   1.00-2.00   sec  6.83 GBytes  58.7 Gbits/sec    0   2.00 MBytes       
[  5]   2.00-3.00   sec  6.79 GBytes  58.4 Gbits/sec    0   2.00 MBytes       
[  5]   3.00-4.00   sec  6.96 GBytes  59.8 Gbits/sec    0   2.00 MBytes       
[  5]   4.00-5.00   sec  6.83 GBytes  58.7 Gbits/sec    0   2.06 MBytes       
[  5]   5.00-6.00   sec  6.81 GBytes  58.5 Gbits/sec    0   2.06 MBytes       
[  5]   6.00-7.00   sec  6.80 GBytes  58.4 Gbits/sec    0   2.06 MBytes       
[  5]   7.00-8.00   sec  6.83 GBytes  58.7 Gbits/sec    0   2.06 MBytes       
[  5]   8.00-9.00   sec  6.35 GBytes  54.6 Gbits/sec    0   3.12 MBytes       
[  5]   9.00-10.00  sec  3.94 GBytes  33.8 Gbits/sec    0   4.68 MBytes       
[  5]  10.00-11.00  sec  4.33 GBytes  37.2 Gbits/sec    1   3.31 MBytes       
[  5]  11.00-12.00  sec  4.51 GBytes  38.7 Gbits/sec    0   3.62 MBytes       
[  5]  12.00-13.00  sec  5.13 GBytes  44.0 Gbits/sec    0   3.62 MBytes       
[  5]  13.00-14.00  sec  5.60 GBytes  48.1 Gbits/sec    0   3.93 MBytes       
[  5]  14.00-15.00  sec  5.23 GBytes  44.9 Gbits/sec    0   3.93 MBytes       
[  5]  15.00-16.00  sec  5.20 GBytes  44.7 Gbits/sec    0   3.93 MBytes       
[  5]  16.00-17.00  sec  4.95 GBytes  42.5 Gbits/sec    0   3.93 MBytes       
[  5]  17.00-18.00  sec  4.91 GBytes  42.2 Gbits/sec    0   3.93 MBytes       
[  5]  18.00-19.00  sec  5.17 GBytes  44.4 Gbits/sec    0   3.93 MBytes       
[  5]  19.00-20.00  sec  5.23 GBytes  44.9 Gbits/sec    0   3.93 MBytes       
[  5]  20.00-21.00  sec  5.22 GBytes  44.8 Gbits/sec    0   3.93 MBytes       
^C[  5]  21.00-21.02  sec  59.6 MBytes  25.5 Gbits/sec    0   3.93 MBytes   

If in the same container, using more ports, starts more iperf3, and in the host starts more clients, the pasta process consumes more CPU.

yuki      176601 17.7  0.1 194008 25176 ?        Rs   10:37   0:12 /usr/bin/pasta --config-net -t 5201-5203:5201-5203 --dns-forward 169.254.1.1 -u none -T none -U none --no-map-gw --quiet --netns /run/user/1000/netns/netns-5bd61a76-f2cf-3eb8-2e49-801b27b9083a --map-guest-addr 169.254.1.2

My CPU is a Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz.

uname -a
Linux archy 7.0.12-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Wed, 10 Jun 2026 08:57:50 +0000 x86_64 GNU/Linux

and I can replicate it in "normal" kernel:

uname -a
Linux archy 7.0.12-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 10 Jun 2026 08:58:02 +0000 x86_64 GNU/Linux

[dgibson]

Background: this was first reported in #23739, but split out to a new bug, because we were primarily investigating a different symptom there.

[dgibson]

High load with iperf3 is, to a certain extent, expected: iperf3 is sending data as fast as it possibly can. Running locally, it's not constrained by a physical network, so it will eventually run into some sort of local processing limit. Inside pasta is pretty much where I'd expect that, particularly without a backend better than plain /dev/net/tun (we have some ideas for this, but they're not close to implementation). Note also:

• pasta load doesn't necessarily grow in proportion to throughput. In a sense it's naturally regulating: the higher the load, the less often we'll be woken, meaning we'll transfer more data during each wakeup cycle, which reduces the load we'll impose per byte or packet.
• This isn't really an apples to apples comparison: iperf3 is sending a lot of data over a single, host to guest TCP connection. BitTorrent, by contrast could be sending data in either or both directions, over a large number of connections, each of which probably has fairly constrained throughput. AIUI those connections could be either TCP or UDP, I'm not sure which is more common in practice.

[dgibson]

It's possible in this case that the high load is just due to a lot of total throughput from qtbittorrent, That would be a bit surprising, though, since that should be constrained by the external network. So we'll keep looking to see if there's a bug in play. Here's some details to start with:

• Do you have a measure of how busy qtbittorrent is? How much data (bytes and or packets) is it sending & receiving per second? How many concurrent connections is it maintaining?
• What's the total capacity of your uplink?
• Is qtbittorrent woorking as expected, apart from the high load?
• What proportion of qtbittorrent's connections are TCP versus UDP? If qtbittorrent is the only major network application running on the host ss -t -u -n should give an idea of this. (This could be relevant, because for TCP we're able to use a high MTU/MSS to the guest, even if it's constrained externally - this can be an important load mitigation factor).