[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.020 / U:186.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site