From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 1 Apr 2003 05:34:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 1 Apr 2003 05:34:14 -0500 Received: from [12.47.58.55] ([12.47.58.55]:56841 "EHLO pao-ex01.pao.digeo.com") by vger.kernel.org with ESMTP id ; Tue, 1 Apr 2003 05:34:13 -0500 Date: Tue, 1 Apr 2003 02:45:48 -0800 From: Andrew Morton To: Jens Axboe Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] rq-dyn-alloc, dynamic request allocation Message-Id: <20030401024548.715ff3c3.akpm@digeo.com> In-Reply-To: <20030401102350.GG812@suse.de> References: <20030401102350.GG812@suse.de> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2003 10:45:30.0064 (UTC) FILETIME=[D0438500:01C2F83B] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jens Axboe wrote: > > Hi, > > This patch adds dynamic request allocation to the block io path. On > systems with lots of disks (and thus queues) it saves a non-significant > amount of low memory. It also allows for much better experimentation > with larger queue lengths, this experimental patch tops the queue depth > off at 16384 (vs 128 before). heh, 16k requests per queue? Last time I played with 1024 certain popular benchmarks ran like a bullet. > Please play with it. Andrew, want a version for -mm? Would be much appreciated, thanks. > */ > static struct request *get_request_wait(request_queue_t *q, int rw) > { > - DEFINE_WAIT(wait); > - struct request_list *rl = &q->rq[rw]; > struct request *rq; > > - spin_lock_prefetch(q->queue_lock); > - > generic_unplug_device(q); > do { > - int block = 0; > + rq = get_request(q, rw, GFP_NOIO); > > - prepare_to_wait_exclusive(&rl->wait, &wait, > - TASK_UNINTERRUPTIBLE); > - spin_lock_irq(q->queue_lock); > - if (!rl->count) > - block = 1; > - spin_unlock_irq(q->queue_lock); > - > - if (block) > + if (!rq) > io_schedule(); hmm. I fear that if a SCHED_FIFO/SCHED_RR task hits this, it will just pick itself to run again in the schedule() and the box locks up. A blk_congestion_wait(WRITE, HZ/50) may be better here. It will send the caller to sleep until someone puts a write request back, which seems appropriate.