[Stgt-devel] More threads for device server

[FUJITA Tomonori]

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.