From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [95.166.99.235] ([95.166.99.235]:60631 "EHLO kernel.dk" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S932257AbZKDUBx (ORCPT ); Wed, 4 Nov 2009 15:01:53 -0500 Date: Wed, 4 Nov 2009 21:01:58 +0100 From: Jens Axboe Subject: Re: Add extra_buff_count flag Message-ID: <20091104200158.GK8742@kernel.dk> References: <66dfd3fe0911031633s5bef0621g99b4164c2dd174d9@mail.gmail.com> <20091104073525.GQ8742@kernel.dk> <66dfd3fe0911040912s377b8b0eqb81fa3cad3db2d2f@mail.gmail.com> <20091104172932.GD8742@kernel.dk> <66dfd3fe0911040939w7629a514l393e3a6360430b54@mail.gmail.com> <20091104174123.GG8742@kernel.dk> <20091104192230.GI8742@kernel.dk> <66dfd3fe0911041131qcd032dem89f3cdfada112989@mail.gmail.com> <20091104193622.GJ8742@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091104193622.GJ8742@kernel.dk> Sender: fio-owner@vger.kernel.org List-Id: fio@vger.kernel.org To: Radha Ramachandran Cc: fio@vger.kernel.org On Wed, Nov 04 2009, Jens Axboe wrote: > > You also mentioned that you saw some kind of a race on io_u->flags > > today, do you by any chance know if you were using iodepth_low or > > iodepth_batch_complete or libaio engine options. > > I think I see an issue when using them and understand why it happens, > > but dont have a clean fix yet, will hopefully have one soon. I was > > wondering if its the same issue you are seeing. > > Basically the issue is we might think the queue is full (because we > > cannot allocate any more io_u (they are probably doing async verify)), > > but the code assumes that if the queue is full, then there is atleast > > one I/O that we can do "io_getevents" on. And that will cause a hang > > in the code. > > I didn't use libaio, I can reproduce it with the sync engine directly > and much easier if using fast "null" verifies. It triggers this assert > in put_io_u(): > > assert((io_u->flags & IO_U_F_FREE) == 0); > > and this in __get_io_u(): > > assert(io_u->flags & IO_U_F_FREE); > > The former I think is just a bug, it's likely a reput or something, but > not sure yet. The latter looks like a race on the flags, since it isn't > always locked down when manipulated. I think this is fixed now, committed a patch for it. -- Jens Axboe