Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Date:   Tue, 10 Oct 2023 04:57:58 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     Bin Lai <sclaibin@gmail.com>
Cc:     mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
        vincent.guittot@linaro.org, akpm@linux-foundation.org,
        dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
        mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-mm@kvack.org, Bin Lai <robinlai@tencent.com>
Subject: Re: [PATCH] sched/wait: introduce endmark in __wake_up_common
Message-ID: <ZSTLxuiJssT9aYb0@casper.infradead.org>
References: <20231010032833.398033-1-robinlai@tencent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231010032833.398033-1-robinlai@tencent.com>
Precedence: bulk

On Tue, Oct 10, 2023 at 11:28:33AM +0800, Bin Lai wrote:
> Without this patch applied, it can cause the waker to fall into an
> infinite loop in some cases. The commit 2554db916586 ("sched/wait: Break
> up long wake list walk") introduces WQ_FLAG_BOOKMARK to break up long
> wake list walk. When the number of walked entries reach 64, the waker
> will record scan position and release the queue lock, which reduces
> interrupts and rescheduling latency.

Maybe we could try removing bookmarks instead?  There was a thread a
while ago where we agreed they weren't actually useful any more.

Patches to follow ...