[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] hw/nvme: fix handling of over-committed queues
From: |
Keith Busch |
Subject: |
Re: [PATCH] hw/nvme: fix handling of over-committed queues |
Date: |
Mon, 28 Oct 2024 09:15:01 -0600 |
On Mon, Oct 28, 2024 at 10:01:50AM +0100, Klaus Jensen wrote:
> On Oct 25 10:45, Keith Busch wrote:
> > On Fri, Oct 25, 2024 at 12:50:45PM +0200, Klaus Jensen wrote:
> > > @@ -1520,9 +1520,16 @@ static void nvme_post_cqes(void *opaque)
> > > nvme_inc_cq_tail(cq);
> > > nvme_sg_unmap(&req->sg);
> > > +
> > > + if (QTAILQ_EMPTY(&sq->req_list) && !nvme_sq_empty(sq)) {
> > > + qemu_bh_schedule(sq->bh);
> > > + }
> > > +
> > > QTAILQ_INSERT_TAIL(&sq->req_list, req, entry);
> > > }
> >
> > Shouldn't we schedule the bottom half after the req has been added to
> > the list? I think everything the callback needs to be written prior to
> > calling qemu_bh_schedule().
> >
>
> Not as far as I know. It is only queued up; it won't be executed
> immediately. It might run next (ASAP) if we are already in a bottom
> half, but not before whatever context we are in returns.
Okay. I was trying to come up with an explanation for why Waldek was
still able to reproduce the problem, and that was all I have so far.