From: Mike Christie <michaelc at cs.wisc.edu> Subject: Re: [Stgt-devel] More threads for device server Date: Mon, 05 Sep 2005 15:38:17 -0500 > > 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? You can configure how many threads IET runs dynamically. Several kernel threads compete for tasks liked to a single list and sleep on a single wait_queue_head. The core IET code put tasks on the list and call wakeup against the wait_queue_head. One of the thread picks up one task, performs it, and sleeps until the completion. Then another thread gets CPU time and works in the same way. > > 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. > > ok then. After reading AIO status (http://lwn.net/Articles/148755/), I guess that it is not ready for us. So I just created a work queue per target instead of using keventd. We can revisit this later. > > 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 > this. Yep. We need to think about it later. |