On Mon, 25 Apr 2011 19:26:14 +0800 Sepherosa Ziehau <[email protected]> wrote:
> On Mon, Apr 25, 2011 at 6:36 PM, Adam Hoka <[email protected]> wrote: > > On Mon, 25 Apr 2011 10:30:58 +0100 > > Alex Hornung <[email protected]> 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
