sched: KIST writes to kernel and get a "wants to write" notification right after
KIST scheduler does call a write to kernel contrary to the vanilla scheduler. This is done through channel_write_to_kernel()
which calls connection_handle_write()
.
That last function will ultimately call connection_or_flushed_some()
which triggers a scheduler_channel_wants_writes()
because of this condition:
datalen = connection_get_outbuf_len(TO_CONN(conn));
if (datalen < OR_CONN_LOWWATER) {
scheduler_channel_wants_writes(TLS_CHAN_TO_BASE(conn->chan));
That is OK if datalen > 0
but useless if datalen == 0
. For KIST, it makes the channel go back in pending state and scheduled because it wants to write. But then if the outbuf or the cmux queue is empty, we end up scheduling a channel that actually does NOT need to write at all.
Could be the fix here is probably simple as:
if (datalen > 0 && datalen < OR_CONN_LOWWATER) {
I suspect with KIST, the datalen will always be 0 because KIST in theory controls exactly what goes in the outbuf and what can be written to the kernel so when it triggers a connection write(), the entire outbuf should be drained (in theory). So the effect of this is that every write to the kernel from KIST triggers a useless "wants to write" event rescheduling the channel. Note that this only happens if the channel is in SCHED_CHAN_WAITING_TO_WRITE
state.