On Wed, Jul 15, 2009 at 1:16 PM, Chris Mason<chris.mason@xxxxxxxxxx> wrote: > On Wed, Jul 15, 2009 at 12:23:47PM -0700, Dan Williams wrote: >> On Mon, Jul 13, 2009 at 7:11 AM, David Woodhouse<dwmw2@xxxxxxxxxxxxx> wrote: >> > We'll want to use these in btrfs too. >> > >> > Signed-off-by: David Woodhouse <David.Woodhouse@xxxxxxxxx> >> >> Do you suspect that btrfs will also want to perform these operations >> asynchronously? I am preparing an updated release of the raid6 >> offload patch kit, but the previous WIP release can be browsed at: > > The short answer is that we'll definitely want to use the async code > where it is available. Btrfs is already wired up to hand off CPU > intensive parts of IO submission (compression, checksumming) to helper > threads. There's some extra ordering so that we can have N threads > checksumming but still send down the actual bios in the proper order. > > Once the btrfs raid5/6 is working well, I'll wire it into the helper > threads as well. Are the raid offload engines fast enough that we won't > want the helper threads when they are available? The api is such that you will not be able to tell ahead of time if the operation is to be offloaded or carried out synchronously (unless of course you disable offload by CONFIG_ASYNC_TX_DMA=n). The current channel allocator hands out channels on a percpu basis so the scheduling of the helper threads can be used as a proxy for scheduling the offload engines. I have considered allowing overloaded channels to spill work back on to the cpu[1], but I need more data on whether this is worthwhile. -- Dan [1]: http://www.intel.com/design/iio/iop341_42.htm -- 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
