Re: GSOC: Device mapper mirror target

[Adam Hoka <adam.hoka@xxxxxxxxx>]

On Mon, 25 Apr 2011 19:26:14 +0800
Sepherosa Ziehau <sepherosa@gmail.com> wrote:

> On Mon, Apr 25, 2011 at 6:36 PM, Adam Hoka <adam.hoka@gmail.com> wrote:
> > On Mon, 25 Apr 2011 10:30:58 +0100
> > Alex Hornung <ahornung@gmail.com> wrote:
> >
> >> On 25/04/11 10:15, Adam Hoka wrote:
> >> >> I also don't see the need of delegating every write to secondary mirror
> >> >> legs to a thread. You definitely need a synchronization thread, but I
> >> >> think you should propagate writes to each of the mirror disks from the
> >> >> same context you are in when you get the requests.
> >> >
> >> > That "thread" could be a workq (which will run in a different thread,
> >> > obviously).
> >>
> >> I know what you mean, but I don't see why you would do it like that. You
> >> should be dispatching writes to all the mirror disks immediately and not
> >> queue them to later dispatch them for a different thread. I see no
> >> advantage to that approach, it makes things more complicated and last
> >> but not least it is also less robust.
> >
> > How do I parallelize the writes then? I dont want to queue and forget them,
> > just want to something like this:
> >
> > - add the jobs to a list
> > - run them in parallel, each in his own thread
> > - wait for completion and collect return values
> >
> > maybe it could be implemented with something like this?
> > im just not sure if I can run one task multiple times in parallel.
> >
> > tq = taskqueue_create("dm-mirror", M_WAITOK, taskqueue_thread_enqueue, &tq);
> > taskqueue_start_threads(&sc->sc_tq, numberofmirrorlegs, TDPRI_KERN_DAEMON, -1, "dm-mirror taskq");
> > ...
> > taskq_enqueue(tq, dmmirror_write_task);
> 
> You could create dedicated threads on each CPU and use netmsg to do
> the work (take a look at net/netisr.c):
> 
> sendmsg(msgport0)
> sendmsg(msgport0)
> sendmsg(msgport0)
> 
> sendmsg(msgport1)
> sendmsg(msgport1)
> sendmsg(msgport1)
> ...
> 
> domsg(msgport0) <----- wait for the result collection on msgport0
> domsg(msgport1) <----- wait for the result collection on msgport1
> ...

This is exactly what I had on my mind! Thanks.
Anyone else thinks this is the proper way to do so?

-- 
NetBSD - Simplicity is prerequisite for reliability