[lkml]   [2004]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kthread vs. dm-daemon
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
>>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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.072 / U:7.592 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site