[Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[Chen Jinghuang]

Hi, I'm seeing a VM boot hang on mainline, and I'd like to understand the
interaction between userspace throttling and the scheduler patch
"e1f078f50478 sched/fair: Combine detach into dequeue when migrating
task".

Host:
aarch64, 96 CPUs (0-95), 4 NUMA nodes:
	node0: 0-23, node1: 24-47, node2: 48-71, node3: 72-95
Mainline kernel tag: 7.2-rc1.

Guest(libvirt/KVM) - described in words:
An aarch64 (virt-6.2) UEFI VM launched with `virsh create`; key config:

- 128 vCPUs (statically placed, oversubscribed — the host has only 96
  physical CPUs).
- host-passthrough CPU model; GICv3; 64 GiB RAM.
- <cputune> has <global_quota> set to 400000; all <vcpupin> and
  <emulatorpin> entries are commented out, so there is no vCPU pinning.
- Storage: qcow2 on virtio-scsi (cache=none, io=native). HPET disabled.

Userspace throttling:
The VM runs under a CPU-quota cap applied on the host. The actual values
from the cgroup controller are:

	cpu.cfs_period_us = 100000
	cpu.cfs_quota_us  = 400000

I also found that if I set cpu.cfs_quota_us to -1, or enlarge it beyond a
certain point, the guest boots fine.

Symptom:
The guest hangs at some command early in boot and never reaches the login
prompt.

Observations:
Only reverting both of the following together makes it boot (neither one
alone suffices):

1. The kernel patch for userspace throttling.
2. The scheduler patch:
   e1f078f50478 ("sched/fair: Combine detach into dequeue when migrating
   task").

Reverting only one of them still hangs; reverting both together boots fine.

Question:
I don't fully understand how these two interact. My rough guess: e1f078f50478
("sched/fair: Combine detach into dequeue when migrating task") affects the
PELT accounting, and the userspace throttling also has logic that affects PELT
accounting. When both are combined, load balancing and subsequent scheduling
behavior may end up misbehaving, stalling the guest.

This looks like a real regression on mainline in the 128-vCPU oversubscribed
VM on a 96-core/4-NUMA host scenario. Any pointer to the correct mechanism or
a fix direction would be very much appreciated.

Thanks,
Chen Jinghuang

Re: [Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[K Prateek Nayak]

Hello Chen,

Thank you for your report.

On 8/25/2026 5:36 PM, Chen Jinghuang wrote:
> Hi, I'm seeing a VM boot hang on mainline, and I'd like to understand the
> interaction between userspace throttling and the scheduler patch
> "e1f078f50478 sched/fair: Combine detach into dequeue when migrating
> task".
> 
> Host:
> aarch64, 96 CPUs (0-95), 4 NUMA nodes:
> 	node0: 0-23, node1: 24-47, node2: 48-71, node3: 72-95
> Mainline kernel tag: 7.2-rc1.
> 
> Guest(libvirt/KVM) - described in words:
> An aarch64 (virt-6.2) UEFI VM launched with `virsh create`; key config:
> 
> - 128 vCPUs (statically placed, oversubscribed — the host has only 96
>   physical CPUs).
> - host-passthrough CPU model; GICv3; 64 GiB RAM.
> - <cputune> has <global_quota> set to 400000; all <vcpupin> and
>   <emulatorpin> entries are commented out, so there is no vCPU pinning.
> - Storage: qcow2 on virtio-scsi (cache=none, io=native). HPET disabled.
> 
> Userspace throttling:
> The VM runs under a CPU-quota cap applied on the host. The actual values
> from the cgroup controller are:
> 
> 	cpu.cfs_period_us = 100000
> 	cpu.cfs_quota_us  = 400000

400ms across 96 CPUs per 100ms seems awfully low. Let me go see if I can
reproduce this.

> 
> I also found that if I set cpu.cfs_quota_us to -1, or enlarge it beyond a
> certain point, the guest boots fine.

Sounds a lot like guest side lock-holder preemption stalling the guest.
If you give it enough time, does the guest progress?

> 
> Symptom:
> The guest hangs at some command early in boot and never reaches the login
> prompt.

What happens if you allow it to boot and then enforce the more
the aggressive limits later? Do you see RCU stalls / lockups?

> 
> Observations:
> Only reverting both of the following together makes it boot (neither one
> alone suffices):
> 
> 1. The kernel patch for userspace throttling.

Are these Aaron's patches too or just the recent rework that I did?
Could you please paste a log of all the reverts.

> 2. The scheduler patch:
>    e1f078f50478 ("sched/fair: Combine detach into dequeue when migrating
>    task").
> 
> Reverting only one of them still hangs; reverting both together boots fine.

Can you check your cgroup stats to see how much time the vCPUs are getting
before and after the revert? Very surprising that e1f078f50478 has some
effect here.

> 
> Question:
> I don't fully understand how these two interact. My rough guess: e1f078f50478
> ("sched/fair: Combine detach into dequeue when migrating task") affects the
> PELT accounting, and the userspace throttling also has logic that affects PELT
> accounting. When both are combined, load balancing and subsequent scheduling
> behavior may end up misbehaving, stalling the guest.
> 
> This looks like a real regression on mainline in the 128-vCPU oversubscribed
> VM on a 96-core/4-NUMA host scenario. Any pointer to the correct mechanism or
> a fix direction would be very much appreciated.

Both, with exit-to-user throttling, and the legacy method, we would have
preempted the vCPU in xfer_to_guest_mode_work():

    if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY))
        schedule();

    if (ti_work & _TIF_NOTIFY_RESUME)
        resume_user_mode_work(NULL);

Previously, task would have taken the schedule() route out, and now it
is done via resume_user_mode_work() -> schedule() / preempt_schedule()

Since e1f078f50478 only takes effect at migration, does 1:1 pinning
help progress the boot?

Are there any splats in your dmesg?

-- 
Thanks and Regards,
Prateek

Re: [Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[chenjinghuang]

On 8/25/2026 9:15 PM, K Prateek Nayak wrote:
> Hello Chen,
> 
> Thank you for your report.
> 
Thanks for your response, Here are the updated test results for your questions:
> On 8/25/2026 5:36 PM, Chen Jinghuang wrote:
>> Hi, I'm seeing a VM boot hang on mainline, and I'd like to understand the
>> interaction between userspace throttling and the scheduler patch
>> "e1f078f50478 sched/fair: Combine detach into dequeue when migrating
>> task".
>>
>> Host:
>> aarch64, 96 CPUs (0-95), 4 NUMA nodes:
>> 	node0: 0-23, node1: 24-47, node2: 48-71, node3: 72-95
>> Mainline kernel tag: 7.2-rc1.
>>
>> Guest(libvirt/KVM) - described in words:
>> An aarch64 (virt-6.2) UEFI VM launched with `virsh create`; key config:
>>
>> - 128 vCPUs (statically placed, oversubscribed — the host has only 96
>>   physical CPUs).
>> - host-passthrough CPU model; GICv3; 64 GiB RAM.
>> - <cputune> has <global_quota> set to 400000; all <vcpupin> and
>>   <emulatorpin> entries are commented out, so there is no vCPU pinning.
>> - Storage: qcow2 on virtio-scsi (cache=none, io=native). HPET disabled.
>>
>> Userspace throttling:
>> The VM runs under a CPU-quota cap applied on the host. The actual values
>> from the cgroup controller are:
>>
>> 	cpu.cfs_period_us = 100000
>> 	cpu.cfs_quota_us  = 400000
> 
> 400ms across 96 CPUs per 100ms seems awfully low. Let me go see if I can
> reproduce this.
> 
>>
>> I also found that if I set cpu.cfs_quota_us to -1, or enlarge it beyond a
>> certain point, the guest boots fine.
> 
> Sounds a lot like guest side lock-holder preemption stalling the guest.
> If you give it enough time, does the guest progress?
> 
Even if given plenty of time, the guest fails to complete booting. During
boot, it first pauses for a while at the early console log:
[    0.003862][    T0] printk: console [tty0] enabled
[    0.004709][    T0] printk: bootconsole [pl11] disabled

Then it progresses a bit and hangs again here:
[  129.095680][    T1] systemd[1]: Finished Create List of Static Device Nodes.
[  129.097121][    T1] systemd[1]: sysinit.target: starting held back, waiting for: systemd-sysctl.service

Softlockups are occasionally triggered inside the guest, but it never reaches
the login prompt.
>>
>> Symptom:
>> The guest hangs at some command early in boot and never reaches the login
>> prompt.
> 
> What happens if you allow it to boot and then enforce the more
> the aggressive limits later? Do you see RCU stalls / lockups?
> 
If I allow the guest to boot normally first by setting echo -1 > cpu.cfs_quota_us,
and then echo 400000 > cpu.cfs_quota_us after boot completes, the guest can be
operated normally without any RCU stalls.
>>
>> Observations:
>> Only reverting both of the following together makes it boot (neither one
>> alone suffices):
>>
>> 1. The kernel patch for userspace throttling.
> 
> Are these Aaron's patches too or just the recent rework that I did?
> Could you please paste a log of all the reverts.
> 
The series of userspace throttling patches includes:
- sched/fair: Add related data structure for task based throttle
- sched/fair: Implement throttle task work and related helpers
- sched/fair: Switch to task based throttle model
- sched/fair: Task based throttle time accounting
- sched/fair: Get rid of throttled_lb_pair()
- sched/fair: Propagate load for throttled cfs_rq
- sched/fair: update_cfs_group() for throttled cfs_rqs
- sched/fair: Do not balance task to a throttled cfs_rq
- sched/fair: Start a cfs_rq on throttled hierarchy with PELT clock throttled
- sched/fair: Prevent cfs_rq from being unthrottled with zero runtime_remaining

Even with e1f078f50478 reverted, switching to commit sched/fair: Switch to task based throttle model
reproduces the hang, whereas switching to the commit sched/fair: Implement throttle task work and related helpers
works fine.

>> 2. The scheduler patch:
>>    e1f078f50478 ("sched/fair: Combine detach into dequeue when migrating
>>    task").
>>
>> Reverting only one of them still hangs; reverting both together boots fine.
> 
> Can you check your cgroup stats to see how much time the vCPUs are getting
> before and after the revert? Very surprising that e1f078f50478 has some
> effect here.
> 
Here are the cgroup statistics sampled 10 seconds apart:

before revert:
cpu.stat:
=== T0 ===
nr_periods 1150
nr_throttled 701
throttled_time 5843715989650
nr_bursts 0
burst_time 0
=== T1 (10s later) ===
nr_periods 1250
nr_throttled 801
throttled_time 6732356889110
nr_bursts 0
burst_time 0

cpuacct.usage:
=== T0 ===
541942826770
=== T1 (10s later) ===
581940183840

after revert:
cpu.stat:
=== T0 ===
nr_periods 2899
nr_throttled 719
throttled_time 3892756326930
nr_bursts 0
burst_time 0
adjust_runtime 0
=== T1 (10s later) ===
nr_periods 2999
nr_throttled 808
throttled_time 4390035054220
nr_bursts 0
burst_time 0
adjust_runtime 0

cpuacct.usage:
=== T0 ===
1016649387110
=== T1 (10s later) ===
1051395917140
>>
>> Question:
>> I don't fully understand how these two interact. My rough guess: e1f078f50478
>> ("sched/fair: Combine detach into dequeue when migrating task") affects the
>> PELT accounting, and the userspace throttling also has logic that affects PELT
>> accounting. When both are combined, load balancing and subsequent scheduling
>> behavior may end up misbehaving, stalling the guest.
>>
>> This looks like a real regression on mainline in the 128-vCPU oversubscribed
>> VM on a 96-core/4-NUMA host scenario. Any pointer to the correct mechanism or
>> a fix direction would be very much appreciated.
> 
> Both, with exit-to-user throttling, and the legacy method, we would have
> preempted the vCPU in xfer_to_guest_mode_work():
> 
>     if (ti_work & (_TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY))
>         schedule();
> 
>     if (ti_work & _TIF_NOTIFY_RESUME)
>         resume_user_mode_work(NULL);
> 
> Previously, task would have taken the schedule() route out, and now it
> is done via resume_user_mode_work() -> schedule() / preempt_schedule()
> 
> Since e1f078f50478 only takes effect at migration, does 1:1 pinning
> help progress the boot?
> 
With 1:1 static vCPU pinning, the issue no longer occurs.
Additionally, if I restrict all vCPU tasks to CPU range 0-3 (e.g. by setting cpuset="0-3"),
the issue also disappears.

> Are there any splats in your dmesg?
> 
>
There are no errors, warnings, or splats in the host dmesg.

Re: [Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[Aaron Lu]

On Tue, Aug 25, 2026 at 12:06:29PM +0000, Chen Jinghuang wrote:
> Hi, I'm seeing a VM boot hang on mainline, and I'd like to understand the
> interaction between userspace throttling and the scheduler patch
> "e1f078f50478 sched/fair: Combine detach into dequeue when migrating
> task".
> 
> Host:
> aarch64, 96 CPUs (0-95), 4 NUMA nodes:
> 	node0: 0-23, node1: 24-47, node2: 48-71, node3: 72-95
> Mainline kernel tag: 7.2-rc1.
> 
> Guest(libvirt/KVM) - described in words:
> An aarch64 (virt-6.2) UEFI VM launched with `virsh create`; key config:
> 
> - 128 vCPUs (statically placed, oversubscribed — the host has only 96
>   physical CPUs).
> - host-passthrough CPU model; GICv3; 64 GiB RAM.
> - <cputune> has <global_quota> set to 400000; all <vcpupin> and
>   <emulatorpin> entries are commented out, so there is no vCPU pinning.
> - Storage: qcow2 on virtio-scsi (cache=none, io=native). HPET disabled.
> 
> Userspace throttling:
> The VM runs under a CPU-quota cap applied on the host. The actual values
> from the cgroup controller are:
> 
> 	cpu.cfs_period_us = 100000
> 	cpu.cfs_quota_us  = 400000
> 
> I also found that if I set cpu.cfs_quota_us to -1, or enlarge it beyond a
> certain point, the guest boots fine.
> 
> Symptom:
> The guest hangs at some command early in boot and never reaches the login
> prompt.
> 

I tried this on an x86 machine with v7.2-rc1 kernel and with quota set
to 4 cpus, the VM booted fine; when I further reduced quota to 1 cpu, the
guest kernel would dump a ton of soft lockups during boot. I also tried
running an old 5.10 kernel(which doesn't have per-task throttle) and it
behaved the same as v7.2-rc1.

The x86 machine has 64cores/128cpus and the VM I created has 128cpus and
128G memory.

> Observations:
> Only reverting both of the following together makes it boot (neither one
> alone suffices):
> 
> 1. The kernel patch for userspace throttling.
> 2. The scheduler patch:
>    e1f078f50478 ("sched/fair: Combine detach into dequeue when migrating
>    task")

I'm curious how you found e1f078f50478, just because it touched pelt?

> 
> Reverting only one of them still hangs; reverting both together boots fine.
> 

On top of v7.2-rc1, right?

> Question:
> I don't fully understand how these two interact. My rough guess: e1f078f50478
> ("sched/fair: Combine detach into dequeue when migrating task") affects the
> PELT accounting, and the userspace throttling also has logic that affects PELT
> accounting. When both are combined, load balancing and subsequent scheduling
> behavior may end up misbehaving, stalling the guest.

Is the host busy? If the host has many idle cpus, even the pelt is
wrecked(which I doubt), it should not cause the qemu task being starved.
The PELT accounting matters when tasks have to compet the same CPU, but
if your host system has many idle cpus, that should not happen.

And from the log you posted for the cpu usage, it appears that task
group is getting cpu time.

Re: [Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[chenjinghuang]

On 8/26/2026 6:00 PM, Aaron Lu wrote:
> On Tue, Aug 25, 2026 at 12:06:29PM +0000, Chen Jinghuang wrote:
>> Hi, I'm seeing a VM boot hang on mainline, and I'd like to understand the
>> interaction between userspace throttling and the scheduler patch
>> "e1f078f50478 sched/fair: Combine detach into dequeue when migrating
>> task".
>>
>> Host:
>> aarch64, 96 CPUs (0-95), 4 NUMA nodes:
>> 	node0: 0-23, node1: 24-47, node2: 48-71, node3: 72-95
>> Mainline kernel tag: 7.2-rc1.
>>
>> Guest(libvirt/KVM) - described in words:
>> An aarch64 (virt-6.2) UEFI VM launched with `virsh create`; key config:
>>
>> - 128 vCPUs (statically placed, oversubscribed — the host has only 96
>>   physical CPUs).
>> - host-passthrough CPU model; GICv3; 64 GiB RAM.
>> - <cputune> has <global_quota> set to 400000; all <vcpupin> and
>>   <emulatorpin> entries are commented out, so there is no vCPU pinning.
>> - Storage: qcow2 on virtio-scsi (cache=none, io=native). HPET disabled.
>>
>> Userspace throttling:
>> The VM runs under a CPU-quota cap applied on the host. The actual values
>> from the cgroup controller are:
>>
>> 	cpu.cfs_period_us = 100000
>> 	cpu.cfs_quota_us  = 400000
>>
>> I also found that if I set cpu.cfs_quota_us to -1, or enlarge it beyond a
>> certain point, the guest boots fine.
>>
>> Symptom:
>> The guest hangs at some command early in boot and never reaches the login
>> prompt.
>>
> 
> I tried this on an x86 machine with v7.2-rc1 kernel and with quota set
> to 4 cpus, the VM booted fine; when I further reduced quota to 1 cpu, the
> guest kernel would dump a ton of soft lockups during boot. I also tried
> running an old 5.10 kernel(which doesn't have per-task throttle) and it
> behaved the same as v7.2-rc1.
> 
> The x86 machine has 64cores/128cpus and the VM I created has 128cpus and
> 128G memory.
> 
My host is an ARM64 machine without SMT, so 96 physical cores correspond to
96 logical CPUs. The VM is configured with 128 vCPUs, which is indeed a typical
CPU oversubscription scenario. In my machine, if I configure the VM with 96 vCPUs,
the issue don't occur either.

>> Observations:
>> Only reverting both of the following together makes it boot (neither one
>> alone suffices):
>>
>> 1. The kernel patch for userspace throttling.
>> 2. The scheduler patch:
>>    e1f078f50478 ("sched/fair: Combine detach into dequeue when migrating
>>    task")
> 
> I'm curious how you found e1f078f50478, just because it touched pelt?
> 
I located these two commits via git bisect:
- Comparison: On an older 5.10 kernel, the same test case (Quota set to 400000 with
  a 128-vCPU VM) boots completely fine, whereas on the mainline kernel, the guest hangs.
- Bisect steps: Without userspace throttling, git bisect pointed to commit e1f078f50478
  ("sched/fair: Combine detach into dequeue when migrating task"). Howevert, reverting
  e1f078f50478 alone on mainline v7.2 still resulted in a hang. Futher bisecting led
  to the userspace throttling patch("sched/fair: Switch to task based throttle model").
  I found that only reverting both e1f078f50478 and the userspace throttling ptach together
  restores normal guest boot.

>>
>> Reverting only one of them still hangs; reverting both together boots fine.
>>
> 
> On top of v7.2-rc1, right?
> 
Yes, the previous test was based on v7.2-rc1. You can also try reproducing it on top
of the official v7.2 tag (commit 8d3ae59288f1).

>> Question:
>> I don't fully understand how these two interact. My rough guess: e1f078f50478
>> ("sched/fair: Combine detach into dequeue when migrating task") affects the
>> PELT accounting, and the userspace throttling also has logic that affects PELT
>> accounting. When both are combined, load balancing and subsequent scheduling
>> behavior may end up misbehaving, stalling the guest.
> 
> Is the host busy? If the host has many idle cpus, even the pelt is
> wrecked(which I doubt), it should not cause the qemu task being starved.
> The PELT accounting matters when tasks have to compet the same CPU, but
> if your host system has many idle cpus, that should not happen.
> 
The host is not running any other workloads besides the tasks associated with starting the
VM. However, because this is an oversubscribed setup, tasks are running across all 96 host
CPUs(even though the utilization on most CPUs is below 10%), so the host don't have many
idle CPUs available.

> And from the log you posted for the cpu usage, it appears that task
> group is getting cpu time.

It seems possible that the task gets throttled shortly after receiving a small time slice
in each period.

Re: [Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[Aaron Lu]

On Thu, Aug 27, 2026 at 11:36:33AM +0800, chenjinghuang wrote:
> On 8/26/2026 6:00 PM, Aaron Lu wrote:
> > On Tue, Aug 25, 2026 at 12:06:29PM +0000, Chen Jinghuang wrote:
> >> Hi, I'm seeing a VM boot hang on mainline, and I'd like to understand the
> >> interaction between userspace throttling and the scheduler patch
> >> "e1f078f50478 sched/fair: Combine detach into dequeue when migrating
> >> task".
> >>
> >> Host:
> >> aarch64, 96 CPUs (0-95), 4 NUMA nodes:
> >> 	node0: 0-23, node1: 24-47, node2: 48-71, node3: 72-95
> >> Mainline kernel tag: 7.2-rc1.
> >>
> >> Guest(libvirt/KVM) - described in words:
> >> An aarch64 (virt-6.2) UEFI VM launched with `virsh create`; key config:
> >>
> >> - 128 vCPUs (statically placed, oversubscribed — the host has only 96
> >>   physical CPUs).
> >> - host-passthrough CPU model; GICv3; 64 GiB RAM.
> >> - <cputune> has <global_quota> set to 400000; all <vcpupin> and
> >>   <emulatorpin> entries are commented out, so there is no vCPU pinning.
> >> - Storage: qcow2 on virtio-scsi (cache=none, io=native). HPET disabled.
> >>
> >> Userspace throttling:
> >> The VM runs under a CPU-quota cap applied on the host. The actual values
> >> from the cgroup controller are:
> >>
> >> 	cpu.cfs_period_us = 100000
> >> 	cpu.cfs_quota_us  = 400000
> >>
> >> I also found that if I set cpu.cfs_quota_us to -1, or enlarge it beyond a
> >> certain point, the guest boots fine.
> >>
> >> Symptom:
> >> The guest hangs at some command early in boot and never reaches the login
> >> prompt.
> >>
> > 
> > I tried this on an x86 machine with v7.2-rc1 kernel and with quota set
> > to 4 cpus, the VM booted fine; when I further reduced quota to 1 cpu, the
> > guest kernel would dump a ton of soft lockups during boot. I also tried
> > running an old 5.10 kernel(which doesn't have per-task throttle) and it
> > behaved the same as v7.2-rc1.
> > 
> > The x86 machine has 64cores/128cpus and the VM I created has 128cpus and
> > 128G memory.
> > 
> My host is an ARM64 machine without SMT, so 96 physical cores correspond to
> 96 logical CPUs. The VM is configured with 128 vCPUs, which is indeed a typical
> CPU oversubscription scenario. In my machine, if I configure the VM with 96 vCPUs,
> the issue don't occur either.
>

OK, so this looks like it has something to do with the task number. More
vCPUs translated to more qemu threads and that caused your guest boot
hang. I think there should be softlockup dumps in your case, is it that
the softlockup detector is not enabled in your guest kernel config?

With this said, I increased vCPU to 256 on this 64core/128cpus Intel host
to see if I can reproduce this. With 4 cpus quota, it managed to boot
the guest. There are several softlockups during boot though and that is
an indication the qemu task is in need of cpu time. I can imagine if I
increase the vCPU number even more or reduce the quota further, it will
eventually hang the guest with tons of softlockup msgs.

[Question] Userspace throttling + "sched/fair: Combine detach into dequeue when migrating task" causes guest boot hang

[Chen Jinghuang]

Hi, I'm seeing a VM boot hang on mainline, and I'd like to understand the
interaction between userspace throttling and the scheduler patch
"e1f078f50478 sched/fair: Combine detach into dequeue when migrating
task".

Host:
aarch64, 96 CPUs (0-95), 4 NUMA nodes:
	node0: 0-23, node1: 24-47, node2: 48-71, node3: 72-95
Mainline kernel tag: 7.2-rc1.

Guest(libvirt/KVM) - described in words:
An aarch64 (virt-6.2) UEFI VM launched with `virsh create`; key config:

- 128 vCPUs (statically placed, oversubscribed — the host has only 96
  physical CPUs).
- host-passthrough CPU model; GICv3; 64 GiB RAM.
- <cputune> has <global_quota> set to 400000; all <vcpupin> and
  <emulatorpin> entries are commented out, so there is no vCPU pinning.
- Storage: qcow2 on virtio-scsi (cache=none, io=native). HPET disabled.

Userspace throttling:
The VM runs under a CPU-quota cap applied on the host. The actual values
from the cgroup controller are:

	cpu.cfs_period_us = 100000
	cpu.cfs_quota_us  = 400000

I also found that if I set cpu.cfs_quota_us to -1, or enlarge it beyond a
certain point, the guest boots fine.

Symptom:
The guest hangs at some command early in boot and never reaches the login
prompt.

Observations:
Only reverting both of the following together makes it boot (neither one
alone suffices):

1. The kernel patch for userspace throttling.
2. The scheduler patch:
   e1f078f50478 ("sched/fair: Combine detach into dequeue when migrating
   task").

Reverting only one of them still hangs; reverting both together boots fine.

Question:
I don't fully understand how these two interact. My rough guess: e1f078f50478
("sched/fair: Combine detach into dequeue when migrating task") affects the
PELT accounting, and the userspace throttling also has logic that affects PELT
accounting. When both are combined, load balancing and subsequent scheduling
behavior may end up misbehaving, stalling the guest.

This looks like a real regression on mainline in the 128-vCPU oversubscribed
VM on a 96-core/4-NUMA host scenario. Any pointer to the correct mechanism or
a fix direction would be very much appreciated.

Thanks,
Chen Jinghuang