Re: This is the fourth time I’ve tried to find what led to the regression of outgoing network speed and each time I find the merge commit 8c94ccc7cd691472461448f98e2372c75849406c

From: Mikhail Gavrilov
Date: Thu Feb 08 2024 - 05:32:40 EST

Next message: Lee Jones: "Re: (subset) [PATCH] backlight: ktz8866: Correct the check for of_property_read_u32"
Previous message: Joao Martins: "Re: [PATCH] iommu/vt-d: Set SSADE when attaching to a parent with dirty tracking"
In reply to: Mathias Nyman: "Re: This is the fourth time I’ve tried to find what led to the regression of outgoing network speed and each time I find the merge commit 8c94ccc7cd691472461448f98e2372c75849406c"
Next in thread: Mathias Nyman: "Re: This is the fourth time I’ve tried to find what led to the regression of outgoing network speed and each time I find the merge commit 8c94ccc7cd691472461448f98e2372c75849406c"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Thu, Feb 8, 2024 at 2:23 PM Mathias Nyman
<mathias.nyman@xxxxxxxxxxxxxxx> wrote:
>
> My guess is that CPU0 spends more time with interrupts disabled than other CPUs.
> Either because it's handling interrupts from some other hardware, or running
> code that disables interrupts (for example kernel code inside spin_lock_irq),
> and thus not able to handle network adapter interrupts at the same rate as CPU23
>

Can this be fixed?
Can I help you here with anything else?

--
Best Regards,
Mike Gavrilov.