[PATCH] Dynamic RAID Stripe Cache Size

, lesser, value. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] -- diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index d59e1bc..1d2b064 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -4934,10 +4934,11 @@ static struct attribute_group raid5_attrs_group = { static int run(mddev_t

[md-raid6-accel PATCH 03/12] md: run stripe operations outside the lock

is the same as in the RAID-5 case. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED] -- diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 9a4959a..af77291 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -894,18 +894,26 @@ static

[md-raid6-accel PATCH 01/12] async_tx: PQXOR implementation

may be processed in CPU (e.g. in case of no DMA descriptors available) it's highly recommended to configure the DMA engine which your system uses to exploit exactly the same Galois polynomial. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED] -- diff

[md-raid6-accel PATCH 02/12] async_tx: RAID-6 recovery implementation

implemented here. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED] -- diff --git a/crypto/async_tx/Kconfig b/crypto/async_tx/Kconfig index b1705d1..b2423e9 100644 --- a/crypto/async_tx/Kconfig +++ b/crypto/async_tx/Kconfig @@ -18,3 +18,7 @@ config

[md-raid6-accel PATCH 06/12] md: req/comp logic for async compute operations

Scheduling and processing the asynchronous computations. handle_stripe will compute a block when a backing disk has failed. Since both RAID-5/6 use the same ops_complete_compute() we should set the second computation target in RAID-5 to (-1) [no target]. Signed-off-by: Yuri Tikhonov [EMAIL

[md-raid6-accel PATCH 11/12] md: remove unused functions

Some clean-up of the replaced or already unnecessary functions. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED] -- diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 9b6336f..1d45887 100644 --- a/drivers/md/raid5.c +++ b/drivers/md

[md-raid6-accel PATCH 04/12] md: common handle_stripe6() infrastructure

We utilize get_stripe_work() to find new work to run. This function is shared with RAID-5. The only RAID-5 specific operation there is PREXOR. Then we call raid_run_ops() to process the requests pending. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL

[md-raid6-accel PATCH 09/12] md: req/comp logic for async expand operations

Support for expanding RAID-6 stripes asynchronously. By setting STRIPE_OP_POSTXOR without setting STRIPE_OP_BIODRAIN the completion path in handle stripe can differentiate expand operations from normal write operations. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail

[md-raid6-accel PATCH 10/12] md: req/comp logic for async I/O operations

I/O submission requests were already handled outside of the stripe lock in handle_stripe. Now that handle_stripe is only tasked with finding work, this logic belongs in raid5_run_ops Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED] -- diff

[md-raid6-accel PATCH 05/12] md: req/comp logic for async write operations

(). This patch introduces one more RAID-5/6 shared function, it is handle_completed_postxor_requests(), to be called when either handle_stripe5() or handle_stripe6() discover the completeness of a post-xor operation for the stripe. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail

[md-raid6-accel PATCH 07/12] md: req/comp logic for async check operations

-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED] -- diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index f0f8d7f..9856a91 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -3327,62 +3327,129 @@ static void handle_parity_checks5(raid5_conf_t *conf

[md-raid6-accel PATCH 08/12] md: req/comp logic for async read operations

When a read bio is attached to the stripe and the corresponding block is marked as R5_UPTODATE, then a biofill operation is scheduled to copy the data from the stripe cache to the bio buffer. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED

[PATCH] Skip bio copy in full-stripe write ops

; SKIP_BIO_SET = 'Y': 70 MBps. The actual test commands used: # mdadm -C /dev/md0 -c 16 -l 5 -n 4 /dev/sd[a-d] # xdd -op write -kbytes 48000 -reqsize 48 -dio -syncwrite -passes 3 -verbose -target /dev/md0 Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Mikhail Cherkashin [EMAIL PROTECTED

Re[2]: Bug in processing dependencies by async_tx_submit() ?

Hi Dan, On 02.11.2007, 3:36:50 you wrote: I am preparing a new patch that replaces ASYNC_TX_DEP_ACK with ASYNC_TX_CHAIN_ACK. The plan is to make the entire chain of dependencies available up until the last transaction is submitted. This allows the entire dependency chain to be walked at

Re: Bug in processing dependencies by async_tx_submit() ?

the entire dependency chain to be walked at async_tx_submit time so that we can properly handle these multiple dependency cases. I'll send it out when it passes my internal tests... Fine. I guess this replacement assumes some modifications to the RAID-5 driver as well. Right? -- Yuri

Re: Bug in processing dependencies by async_tx_submit() ?

, depend_tx, NULL, NULL); } else { tx-parent = NULL; tx-tx_submit(tx); Regards, Yuri On Thursday 01 November 2007 06:01, Dan Williams wrote: On Wed, 2007-10-31 at 09:21 -0700, Yuri Tikhonov wrote: Hello Dan, I've run into a problem with the h/w

Re: async_tx: get best channel

if I'll have no asynchronous COPY : ) Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo

async_tx: get best channel

-- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: md raid acceleration and the async_tx api

Hi Dan, On Friday 07 September 2007 20:02, you wrote: You need to fetch from the 'md-for-linus' tree. But I have attached them as well. git fetch git://lost.foo-projects.org/~dwillia2/git/iop md-for-linus:md-for-linus Thanks. Unrelated question. Comparing the drivers/md/raid5.c file

Fwd: Re: md raid acceleration and the async_tx api

Hi Dan, On Thursday 30 August 2007 23:34, you wrote: ... Looking at it again I see that what I added would not affect the failure you are seeing. However I noticed that you are using a broken version of the stripe-queue and cache_arbiter patches. In the current revisions the dev_q-flags

Re: md raid acceleration and the async_tx api

Hi Dan, On Monday 27 August 2007 23:12, you wrote: This still looks racy... I think the complete fix is to make the R5_Wantfill and dev_q-toread accesses atomic. Please test the following patch (also attached) and let me know if it fixes what you are seeing: Your approach doesn't help,

md raid acceleration and the async_tx api

Hello, I tested the h/w accelerated RAID-5 using the kernel with PAGE_SIZE set to 64KB and found the bonnie++ application hangs-up during the Re-writing test. I made some investigations and discovered that the hang-up occurs because one of the mpage_end_io_read() calls is missing (these are

Re: [PATCH 2.6.21-rc4 01/15] dmaengine: add base support for the async_tx api

Hi Dan, Functions dma_async_memcpy_buf_to_buf(), dma_async_memcpy_buf_to_pg() and dma_async_memcpy_pg_to_pg() are practically identical. Maybe it makes sense to extract the common part into a separate inline function? Somehow like this: static inline dma_cookie_t dma_async_memcpy (

Re: [PATCH] [PPC32] ADMA support for PPC 440SPe processors.

Hi Dan, On Friday 16 March 2007 21:00, you wrote: Here are some additional comments/nits: +/* + * Init DMA0/1 and XOR engines; allocate memory for DMAx FIFOs; set platform_device + * memory resources addresses + */ +static void ppc440spe_configure_raid_devices(void) Any reason not

Re: [PATCH 00/12] md raid acceleration and the async_tx api

Hello, Dan. It seems there is a bug in your 06.11.30 raid acceleration patch-set. I tried to run the Linux s/w RAID-5 driver patched with your 06.11.30 patch-set and found that it fails during write operations when the RAID-5 array consists of 6 or more number of drives (I tested up to 8

Re: [PATCH 001 of 006] raid5: Move write operations to a work queue

Hello, Dan. I've looked through your patches, and have some suggestions about write operations processing. In the current implementation of the Raid5 driver the RMW operation won't begin until old blocks in the stripe cache, which are to be rewritten, become UPTODATE. But if you have