From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Ledford Subject: Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun() Date: Tue, 17 Dec 2002 20:00:50 -0500 Sender: linux-scsi-owner@vger.kernel.org Message-ID: <20021218010050.GF28100@redhat.com> References: <170040000.1040080786@aslan.btc.adaptec.com> <20021217054102.GH13989@redhat.com> <797140000.1040156703@aslan.btc.adaptec.com> <20021217222459.GD28100@redhat.com> <20021217223341.A26529@infradead.org> <3DFFAB33.F174D272@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <3DFFAB33.F174D272@digeo.com> List-Id: linux-scsi@vger.kernel.org To: Andrew Morton Cc: Christoph Hellwig , "Justin T. Gibbs" , linux-scsi@vger.kernel.org On Tue, Dec 17, 2002 at 02:54:43PM -0800, Andrew Morton wrote: > > wakes up. > > I think (hope) the plan there is to do away with the preallocated > per-queue request lists altogether. Just allocate the requests > direct from slab at __make_request(). So, what is the overhead of using the slab allocator on each command? If you prealloc a reasonable queue, allocation from that queue is O(1). Would we suffer no/little/large penalty using slab instead? /me hasn't gone looking in the slab allocator and has no idea how well it actually works at being a cache... Second issue I have is that overly large request queues have never seemed to help performance in my experience. At a certain point the overhead of the queue and merging so many requests, etc. becomes greater than the gain of the increased depth and starts to slow things back down. So, my question to you, is why would we *want* to be able to have huge queues? -- Doug Ledford 919-754-3700 x44233 Red Hat, Inc. 1801 Varsity Dr. Raleigh, NC 27606