lkml.org 
[lkml]   [2004]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
>>>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.
-
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/

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