Re: 2.4.20: Proccess stuck in __lock_page ...

Jens Axboe
2003-05-28T08:17:52Z

On Wed, May 28 2003, Andrew Morton wrote:
> Jens Axboe <axboe@suse.de> wrote:
> >
> > > that one, the answer is YES.
> >
> > That's the one, yes. Andrew, looks like your patch brought out some
> > really bad behaviour.
>
> Yes, but why?
>
> It'd be interesting if any of these changes make a difference.
>
>
> drivers/block/ll_rw_blk.c | 7
> fs/buffer.c | 3030 ++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 3033 insertions(+), 4 deletions(-)
>
> diff -puN drivers/block/ll_rw_blk.c~a drivers/block/ll_rw_blk.c
> --- 24/drivers/block/ll_rw_blk.c~a 2003-05-28 00:48:09.000000000 -0700
> +++ 24-akpm/drivers/block/ll_rw_blk.c 2003-05-28 00:50:02.000000000 -0700
> @@ -590,10 +590,10 @@ static struct request *__get_request_wai
> register struct request *rq;
> DECLARE_WAITQUEUE(wait, current);
>
> - generic_unplug_device(q);
> - add_wait_queue_exclusive(&q->wait_for_requests[rw], &wait);
> + add_wait_queue(&q->wait_for_requests[rw], &wait);
> do {
> set_current_state(TASK_UNINTERRUPTIBLE);
> + generic_unplug_device(q);
> if (q->rq[rw].count == 0)
> schedule();
> spin_lock_irq(&io_request_lock);
> @@ -829,8 +829,7 @@ void blkdev_release_request(struct reque
> */
> if (q) {
> list_add(&req->queue, &q->rq[rw].free);
> - if (++q->rq[rw].count >= q->batch_requests &&
> - waitqueue_active(&q->wait_for_requests[rw]))
> + if (++q->rq[rw].count >= q->batch_requests)
> wake_up(&q->wait_for_requests[rw]);
> }
> }

The unplug() move could be the key, in theory we could end up having to
unplug the queue again.

Question to the ones seeing the stalls - does a sysrq-s make things go
again?

--
Jens Axboe