DragonFly kernel List (threaded) for 2011-04
Re: GSOC: Device mapper mirror target
On Mon, Apr 25, 2011 at 6:36 PM, Adam Hoka <firstname.lastname@example.org> wrote:
> On Mon, 25 Apr 2011 10:30:58 +0100
> Alex Hornung <email@example.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):
domsg(msgport0) <----- wait for the result collection on msgport0
domsg(msgport1) <----- wait for the result collection on msgport1
Tomorrow Will Never Die