On 3/21/18 1:10 PM, Jens Axboe wrote:
> On 3/21/18 1:03 PM, Jens Axboe wrote:
>> Shoot, I think I see what it is. Some commands we punt to out-of-line
>> sending, others we do inline. STOP/QUIT are inline, whereas the ts/gs/du
>> are not. So we could potentially have a situation where we queue up the
>> ts/gs/du, but then process the STOP/QUIT first. If we do that, then we
>> don't get any output...
>>
>> Let me think about this for a bit, and see what I can come up with.
>
> Can you try with this? Can be improved to have the thread signal us,
> but it should be a rare occurrence and a 1ms stall from this context
> isn't a concern.
>
> diff --git a/server.c b/server.c
> index 65d4484edae5..52bcf7bf44c6 100644
> --- a/server.c
> +++ b/server.c
> @@ -551,9 +551,15 @@ static void fio_net_queue_entry(struct sk_entry *entry)
> {
> struct sk_out *sk_out = pthread_getspecific(sk_out_key);
>
> - if (entry->flags & SK_F_INLINE)
> + if (entry->flags & SK_F_INLINE) {
> + /*
> + * Honor ordering - if the out-of-line queue isn't empty,
> + * wait for it to drain before proceeding.
> + */
> + while (!flist_empty(&sk_out->list))
> + usleep(1000);
> handle_sk_entry(sk_out, entry);
> - else {
> + } else {
> sk_lock(sk_out);
> flist_add_tail(&entry->list, &sk_out->list);
> sk_unlock(sk_out);
Actually, this probably won't work since we also end up doing
inline commands from the loop that handles the out-of-line
commands. So the above can deadlock in that scenario.
Back to the drawing board...
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe fio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
