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? -- Dan -- 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
