Re: slave_destroy called in scsi_scan.c:scsi_probe_and_add_lun()

[Andrew Morton <akpm@digeo.com>]

Doug Ledford wrote:
> 
> 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...

It's wickedly quick.  There won't be a problem there...

> 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?
> 

Generally, huge queues don't appear to buy us much.  And in principle
they shouldn't, because we should be ordering write better at the VFS layer.

In practice, I expect there will be certain workloads at which the VFS
is known to behave very suboptimally in which the huge queues will
make a large difference.  Mainly the "seek all around a huge file writing
stuff" workload.

The other "in principle" thing here is that the VM/VFS should _not_
be dependent on request exhaustion for its own throttling, because
that will fail if there are a large number of disks, or if the
machine has a teeny amount of memory.

So I expect that in practice we would be unlikely to go beyond
128 requests per direction per queue.  But it should be an
option, and it should work well.