Re: kthread vs. dm-daemon

[Christophe Saout <christophe@saout.de>]

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. I've switched dm-crypt to kthread and the
overhead is minimal. I hope I got it right though but it seems to work
just fine.

> 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? What about
writes? They are currently running in the caller context (usually
pdflush).

> I guess you could also just do a thread per target instance, but maybe 
> this was ruled as excessive for thousands of DM devices?

Probably. I originally had one thread per device too for dm-crypt
because I didn't think about it but Joe changed it a single dm-daemon
thread (after porting the dm-daemon code to 2.6). He was right because
the different requests can't depend on each other and deadlock because
the daemon will never wait for io.