Messages in this thread | | | Subject | Re: kthread vs. dm-daemon | From | Christophe Saout <> | Date | Mon, 16 Feb 2004 01:04:14 +0100 |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |