Re: kthread vs. dm-daemon

[Mike Christie]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/