lkml.org 
[lkml]   [2022]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: stalling IO regression since linux 5.12, through 5.18


    On Tue, Aug 16, 2022, at 11:25 AM, Nikolay Borisov wrote:
    > On 16.08.22 г. 17:22 ч., Chris Murphy wrote:
    >>
    >>
    >> On Sun, Aug 14, 2022, at 4:28 PM, Chris Murphy wrote:
    >>> On Fri, Aug 12, 2022, at 2:02 PM, Jens Axboe wrote:
    >>>> Might be worth trying to revert those from 5.12 to see if they are
    >>>> causing the issue? Jan, Paolo - does this ring any bells?
    >>>
    >>> git log --oneline --no-merges v5.11..c03c21ba6f4e > bisect.txt
    >>>
    >>> I tried checking out a33df75c6328, which is right before the first bfq
    >>> commit, but that kernel won't boot the hardware.
    >>>
    >>> Next I checked out v5.12, then reverted these commits in order (that
    >>> they were found in the bisect.txt file):
    >>>
    >>> 7684fbde4516 bfq: Use only idle IO periods for think time calculations
    >>> 28c6def00919 bfq: Use 'ttime' local variable
    >>> 41e76c85660c bfq: Avoid false bfq queue merging
    >>>>>> a5bf0a92e1b8 bfq: bfq_check_waker() should be static
    >>> 71217df39dc6 block, bfq: make waker-queue detection more robust
    >>> 5a5436b98d5c block, bfq: save also injection state on queue merging
    >>> e673914d52f9 block, bfq: save also weight-raised service on queue merging
    >>> d1f600fa4732 block, bfq: fix switch back from soft-rt weitgh-raising
    >>> 7f1995c27b19 block, bfq: re-evaluate convenience of I/O plugging on rq arrivals
    >>> eb2fd80f9d2c block, bfq: replace mechanism for evaluating I/O intensity
    >>>>>> 1a23e06cdab2 bfq: don't duplicate code for different paths
    >>> 2391d13ed484 block, bfq: do not expire a queue when it is the only busy
    >>> one
    >>> 3c337690d2eb block, bfq: avoid spurious switches to soft_rt of
    >>> interactive queues
    >>> 91b896f65d32 block, bfq: do not raise non-default weights
    >>> ab1fb47e33dc block, bfq: increase time window for waker detection
    >>> d4fc3640ff36 block, bfq: set next_rq to waker_bfqq->next_rq in waker
    >>> injection
    >>> b5f74ecacc31 block, bfq: use half slice_idle as a threshold to check
    >>> short ttime
    >>>
    >>> The two commits prefixed by >>> above were not previously mentioned by
    >>> Jens, but I reverted them anyway because they showed up in the git log
    >>> command.
    >>>
    >>> OK so, within 10 minutes the problem does happen still. This is
    >>> block/bfq-iosched.c resulting from the above reverts, in case anyone
    >>> wants to double check what I did:
    >>> https://drive.google.com/file/d/1ykU7MpmylJuXVobODWiiaLJk-XOiAjSt/view?usp=sharing
    >>
    >> Any suggestions for further testing? I could try go down farther in the bisect.txt list. The problem is if the hardware falls over on an unbootable kernel, I have to bug someone with LOM access. That's a limited resource.
    >>
    >>
    >
    > How about changing the scheduler either mq-deadline or noop, just to see
    > if this is also reproducible with a different scheduler. I guess noop
    > would imply the blk cgroup controller is going to be disabled

    I already reported on that: always happens with bfq within an hour or less. Doesn't happen with mq-deadline for ~25+ hours. Does happen with bfq with the above patches removed. Does happen with cgroup.disabled=io set.

    Sounds to me like it's something bfq depends on and is somehow becoming perturbed in a way that mq-deadline does not, and has changed between 5.11 and 5.12. I have no idea what's under bfq that matches this description.

    --
    Chris Murphy

    \
     
     \ /
      Last update: 2022-08-16 17:37    [W:2.681 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site