On 6/28/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
Hi Dan, On Mon, 25 Jun 2007, Dan Williams wrote: > Yes you are right, ARM does not flush L1 when prev==next in switch_mm. > > > Perhaps something else is at fault here. > > > I'll try and dig a bit deeper... BTW: static int __init iop_adma_init (void) { + iop_adma_workqueue = create_workqueue("iop-adma"); + if (!iop_adma_workqueue) + return -ENODEV; + Could you also try upping the prio of all the "iop-adma" threads?
Unfortunately setting the thread to real time priority makes throughput slightly worse. Instead of floating around 35MB/s the resync speed is stuck around 30MB/s: [ iop-adma: hi-prio workqueue based callbacks ] iq81340mc:~# cat /proc/mdstat Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md0 : active raid5 sdd[4] sdc[2] sdb[1] sda[0] 468872448 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] [>....................] recovery = 3.9% (6107424/156290816) finish=84.9min speed=29448K/sec The iop-adma tasklet cleans up any completed descriptors and in the process calls any attached callbacks. For the raid5 resync case the callback is simply: static void ops_complete_check(void *stripe_head_ref) { struct stripe_head *sh = stripe_head_ref; int pd_idx = sh->pd_idx; pr_debug("%s: stripe %llu\n", __FUNCTION__, (unsigned long long)sh->sector); if (test_and_clear_bit(STRIPE_OP_MOD_DMA_CHECK, &sh->ops.pending) && sh->ops.zero_sum_result == 0) set_bit(R5_UPTODATE, &sh->dev[pd_idx].flags); set_bit(STRIPE_OP_CHECK, &sh->ops.complete); set_bit(STRIPE_HANDLE, &sh->state); release_stripe(sh); } [ iop-adma: tasklet based callbacks ] iq81340mc:~# cat /proc/mdstat Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md0 : active raid5 sdd[4] sdc[2] sdb[1] sda[0] 468872448 blocks level 5, 64k chunk, algorithm 2 [4/3] [UUU_] [=>...................] recovery = 5.1% (8024248/156290816) finish=47.9min speed=51486K/sec -- Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/