2012/8/8 Dan Williams <dan.j.williams@xxxxxxxxx>: > On Tue, Jul 31, 2012 at 8:40 PM, Shaohua Li <shli@xxxxxxxxxx> wrote: >> This is a new tempt to make raid5 handle stripes in multiple threads, as >> suggested by Neil to have maxium flexibility and better numa binding. It >> basically is a combination of my first and second generation patches. By >> default, no multiple thread is enabled (all stripes are handled by raid5d). >> >> An example to enable multiple threads: >> #echo 3 > /sys/block/md0/md/auxthread_number >> This will create 3 auxiliary threads to handle stripes. The threads can run >> on any cpus and handle stripes produced by any cpus. >> >> #echo 1-3 > /sys/block/md0/md/aux0_cpulist >> This will bind auxiliary thread 0 to cpu 1-3, and this thread will only handle >> stripes produced by cpu 1-3. User tool can further change the thread's >> affinity, but the thread can only handle stripes produced by cpu 1-3 till the >> sysfs entry is changed again. >> >> If stripes produced by a CPU aren't handled by any auxiliary thread, such >> stripes will be handled by raid5d. Otherwise, raid5d doesn't handle any >> stripes. >> >> Please let me know how do you think about it. I'll split the patch to a more >> reviewable form if no one objects the idea. >> >> Signed-off-by: Shaohua Li <shli@xxxxxxxxxxxx> > > Looks ok to me. > > I think the md_sysfs_entry changes are probably asking for a new > md_thread kobj_type in the hierarchy rather than sprinkling a > md_sysfs_entry around. Similar to what happens for rdevs... and I > expect the threads may grow more attributes once there. > > /sys/block/mdX/md/threadX/mask > ...active? > ...idle? Sure, this makes sense. I'll sort it out in patch submit. -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
