Re: kthread vs. dm-daemon

[Christophe Saout <christophe@saout.de>]

Am Mo, den 16.02.2004 schrieb Mike Christie um 02:04:

> > 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.

You mean beacause the caller can block and this affects other devices
with free requests too. Hmm.

> > 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?

I have to call queue_work with a work_struct. queue_work will most
likely be called from interrupt context. The bio will be decrypted on
the same cpu as the interrupt occurs. If the driver returns a bunch of
bio's at once they would all be decrypted on the same cpu sequentally.
So it depends on the irq balancing.

What could be done (probably not with work queues) is: If there is a bio
to decrypt the end_io handler finds a free cpu (empty queue) and puts
the bio there. Another possibility: If there is work it gets just added
to a global list and all threads on all cpu's get fired. The fastest one
will pick a bio, the next one the second... monster cache trashing? I
don't know.