[Stgt-devel] More threads for device server
michaelc at cs.wisc.edu
Mon Sep 5 22:38:17 CEST 2005
FUJITA Tomonori wrote:
> Targets need to perform multiple SCSI commands at the same time. If we
> use synchronous APIs, the work queue framework is not sufficient
> because it cannot perform lots of SCSI commands simultaneously.
Umm, I was just reccomending a work queue becuase you can create them
either as a one thread per proc or a single threaded one. So if you like
the work queue interface you can just create a bunch of
single-threaded-workqueuues instead of creating a bunch of threads.
> There are two options: we need to create lots of kernel threads
> calling kthread_create several times (like IET) or we need to use
> asynchronous APIs with the work queue framework.
Are you creating a thread per command that can get queued or how do you
determine how many threads?
I don't think that
> having lots of kernel threads is so bad, though it makes the stgt code
> complicated and dirty a bit. So I'll try AIO later with work queue per
> target. Work queue per device is not necessary, though it fit for
> SAM-3 theoretically.
> The last topic is that how to prevent a device from being removed (by
> an user) while it has active I/O operations. There are many ways to do
> that. I was just thought about things like the following.
> stgt_device_destory() sets DEVICE_DEL bit (device->state). It prevents
> queuecommand from putting new commands to the device. Then,
> stgt_device_destory() calls flush_workqueue() to wait all commands to
> finish and then frees the resources.
That sounds about right. We also will have to deal with people suddenly
removing targets too. I mean someone just yanking the controller from
the box :) We are going to have to do some more lifetime management for
More information about the stgt