Messages in this thread | | | Date | Sun, 15 Feb 2004 17:04:19 -0800 | From | Mike Christie <> | Subject | Re: 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/
| |