> On Oct 28, 2025, at 14:41, Joel Jacobson <[email protected]> wrote:
>
> On Tue, Oct 28, 2025, at 02:02, Chao Li wrote:
>>>> From this perspective, we need to add a new field
>>>> adviancingTillPos to QueueBackendStatus. (This field was also missing
>>>> from my proposed patch).
>>>
>>> I'm doubtful yet another field is worth the added complexity cost.
>>>
>>> Before increasing the complexity further, I think we should first
>>> try to simulate somewhat realistic workloads, to see if we actually
>>> have a problem first.
>>>
>>> /Joel
>>>
>>
>> I don’t think that’s extra complexity, IMO, that just ensure “direct
>> advancement” to be fully functional.
>
> An extra field is by definition extra complexity;
> If it's worth it depends on how much we would gain from it,
> that's why I'm doubtful it's worth it.
>
> The extra adviancingTillPos field would only avoid wakeups in some
> scenarios, if you study the example given by Arseniy, it's easy to see
> why we would really need something like a the list of skip ranges
> Arseniy suggested, per backend, for it to be complete,
> but that's even more complexity.
>
> I don't think it's too bad for a backend to read through the entire
> queue, even if it contains some entires that are not interesting, when a
> backend is awaken, processing is fast, that's not the big cost here,
> what really costs is the context switches. But I've been wrong before,
> so could be wrong again of course. This is just based on my intuition.
>
>> But anyway, we should run some load tests to verify every solution to
>> see how much they really improve. Do you already have or plan to work
>> on a load test script?
>
> Yes, I'm currently working on a combined benchmark / correctness test suite.
>
Cool. Then we can run the benchmark and decide.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
