Re: kthread vs. dm-daemon

[Mike Christie <mikenc@us.ibm.com>]

Christophe Saout wrote:
> Am So, den 15.02.2004 schrieb Mike Christie um 23:13:
> 
> 
>>>Making dm-daemon use the kthread primitives would make dm-daemon a very
>>>small and stupid wrapper. Changing all dm targets to handle worker
>>>thread notification themselves would result in unnecessary code
>>>duplication.
>>
>>When dm-multipath is more stable it could be using a work queue (my 
>>patch was prematurely sent). Imagine a large number of dm-mp devices 
>>multipathing across two fabrics and one switch failing. Every dm-mp 
>>device could be resubmitting io at the same time.
> 
> 
> I've thought of workqueues but at least for the snapshot and crypt
> target they're overkill. 

It is a bigger problem for targets submitting io becuase the underlying 
device's queue could hit nr_requests.

> 
>>If every write for every dm-raid1 device is going through 
>>a single dm-daemon, it could become a bottleneck.
> 
> 
> Hmm. The read decryption in dm-crypt is also a only-one-cpu-at-a-time
> thing. Didn't anybody notice that? Cryptoloop has the same limitation.
> I don't know how that could be handled differently. Every successful
> read gets dispatched to the next free cpu and decrypted? 

You do not have to create a work_struct for every read. Why not just 
have a bio-successful-reads-queue and a workstruct per device? That way 
you can at least have num cpu devices running in parallel.