All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jens.axboe@oracle.com>
To: Ravi Krishnamurthy <Ravi_Krishnamurthy@adaptec.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Fwd: Block driver freezes when using CFQ]
Date: Mon, 30 Oct 2006 09:22:33 +0100	[thread overview]
Message-ID: <20061030082233.GL4563@kernel.dk> (raw)
In-Reply-To: <454313C9.4010602@adaptec.com>

On Sat, Oct 28 2006, Ravi Krishnamurthy wrote:
> Hi all,
> 
>    I have written a block driver that registers a virtual device and
> routes requests to appropriate real devices after some re-mapping of
> the requests. I am testing the driver by creating a filesystem on the
> virtual device and copying a large number of files on to it. The test
> causes the device to become unresponsive after some time. After some
> debugging, I noticed that this happens only if the I/O scheduler being
> used is CFQ. I have not had any trouble if the scheduler is noop,
> anticipatory or deadline. The problem occurs on all the kernels I have
> tested - 2.6.18-rc2, 2.6.18-rc4, 2.6.19-rc3.
> 
> Below are some details about the driver and what I have observed during
> testing:
> 
> The request function registered by my driver is a simple loop -
> 
>   while ((req = elv_next_request(q))) {
>         blkdev_dequeue_request(req);
> 
>         /*
>          Add request to an internal queue for further processing
>          Wake up thread to start processing the queue
>          Update some variables for book-keeping
>          */
>   }
> 
> Completed requests are handled in a different thread -
>   while (work to be done) {
>       /*
>         Dequeue completed requests from internal queue
>         Call end_that_request_first() and end_that_request_last()
>         Update some variables for book-keeping
>       */
>   }

The io scheduler is not obligated to recall your request handling
function, _unless_ you have no pending io at the point where
elv_next_request() returns NULL but there are things pending. IOW, when
you complete your requests you want to just recall your request handling
function. Just insert something ala:

        if (elv_next_request(q))
                q->request_fn(q);

when you are done completing requests.

Does that fix it?

-- 
Jens Axboe


       reply	other threads:[~2006-10-30  8:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <454313C9.4010602@adaptec.com>
2006-10-30  8:22 ` Jens Axboe [this message]
2006-10-31  4:57   ` Block driver freezes when using CFQ Ravi Krishnamurthy
2006-10-31  7:10     ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061030082233.GL4563@kernel.dk \
    --to=jens.axboe@oracle.com \
    --cc=Ravi_Krishnamurthy@adaptec.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.