1. 16 Feb, 2017 1 commit
    • Dan Williams's avatar
      async_tx: deprecate broken support for channel switching · b802c841
      Dan Williams authored
      Back in 2011, Russell pointed out that the "async_tx channel switch"
      capability was violating expectations of the dma mapping api [1]. At the
      time the existing uses were reviewed as still usable, but that longer
      term we needed a rework of the raid offload implementation. While some
      of the framework for a fixed implementation was introduced in 2012 [2],
      the wider rewrite never materialized.
      There continues to be interest in raid offload with new dma/raid engine
      drivers being submitted. Those drivers must not build on top of the
      broken channel switching capability.
      Prevent async_tx from using an offload engine if the channel switching
      capability is enabled. This still allows the engine to be used for other
      purposes, but the broken way async_tx uses these engines for raid will
      be disabled. For configurations where this causes a performance
      regression the only solution is to start the work of eliminating the
      async_tx api and moving channel management into the raid code directly
      where it can manage marshalling an operation stream between multiple dma
      [1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036753.html
      [2]: https://lkml.org/lkml/2012/12/6/71
      Cc: Anatolij Gustschin <agust@denx.de>
      Cc: Anup Patel <anup.patel@broadcom.com>
      Cc: Rameshwar Prasad Sahu <rsahu@apm.com>
      Cc: Saeed Bishara <saeed.bishara@gmail.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reported-by: default avatarRussell King <linux@armlinux.org.uk>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
  2. 21 Apr, 2015 1 commit
    • Markus Stockhausen's avatar
      md/raid5: activate raid6 rmw feature · 584acdd4
      Markus Stockhausen authored
      Glue it altogehter. The raid6 rmw path should work the same as the
      already existing raid5 logic. So emulate the prexor handling/flags
      and split functions as needed.
      1) Enable xor_syndrome() in the async layer.
      2) Split ops_run_prexor() into RAID4/5 and RAID6 logic. Xor the syndrome
      at the start of a rmw run as we did it before for the single parity.
      3) Take care of rmw run in ops_run_reconstruct6(). Again process only
      the changed pages to get syndrome back into sync.
      4) Enhance set_syndrome_sources() to fill NULL pages if we are in a rmw
      run. The lower layers will calculate start & end pages from that and
      call the xor_syndrome() correspondingly.
      5) Adapt the several places where we ignored Q handling up to now.
      Performance numbers for a single E5630 system with a mix of 10 7200k
      desktop/server disks. 300 seconds random write with 8 threads onto a
      3,2TB (10*400GB) RAID6 64K chunk without spare (group_thread_cnt=4)
      bsize   rmw_level=1   rmw_level=0   rmw_level=1   rmw_level=0
              skip_copy=1   skip_copy=1   skip_copy=0   skip_copy=0
         4K      115 KB/s      141 KB/s      165 KB/s      140 KB/s
         8K      225 KB/s      275 KB/s      324 KB/s      274 KB/s
        16K      434 KB/s      536 KB/s      640 KB/s      534 KB/s
        32K      751 KB/s    1,051 KB/s    1,234 KB/s    1,045 KB/s
        64K    1,339 KB/s    1,958 KB/s    2,282 KB/s    1,962 KB/s
       128K    2,673 KB/s    3,862 KB/s    4,113 KB/s    3,898 KB/s
       256K    7,685 KB/s    7,539 KB/s    7,557 KB/s    7,638 KB/s
       512K   19,556 KB/s   19,558 KB/s   19,652 KB/s   19,688 Kb/s
      Signed-off-by: default avatarMarkus Stockhausen <stockhausen@collogia.de>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
  3. 03 Jul, 2013 1 commit
  4. 09 Sep, 2009 1 commit
    • Dan Williams's avatar
      dmaengine: add fence support · 0403e382
      Dan Williams authored
      Some engines optimize operation by reading ahead in the descriptor chain
      such that descriptor2 may start execution before descriptor1 completes.
      If descriptor2 depends on the result from descriptor1 then a fence is
      required (on descriptor2) to disable this optimization.  The async_tx
      api could implicitly identify dependencies via the 'depend_tx'
      parameter, but that would constrain cases where the dependency chain
      only specifies a completion order rather than a data dependency.  So,
      provide an ASYNC_TX_FENCE to explicitly identify data dependencies.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
  5. 30 Aug, 2009 4 commits
    • Dan Williams's avatar
      async_tx: add support for asynchronous RAID6 recovery operations · 0a82a623
      Dan Williams authored
       async_raid6_2data_recov() recovers two data disk failures
       async_raid6_datap_recov() recovers a data disk and the P disk
      These routines are a port of the synchronous versions found in
      drivers/md/raid6recov.c.  The primary difference is breaking out the xor
      operations into separate calls to async_xor.  Two helper routines are
      introduced to perform scalar multiplication where needed.
      async_sum_product() multiplies two sources by scalar coefficients and
      then sums (xor) the result.  async_mult() simply multiplies a single
      source by a scalar.
      This implemention also includes, in contrast to the original
      synchronous-only code, special case handling for the 4-disk and 5-disk
      array cases.  In these situations the default N-disk algorithm will
      present 0-source or 1-source operations to dma devices.  To cover for
      dma devices where the minimum source count is 2 we implement 4-disk and
      5-disk handling in the recovery code.
      [ Impact: asynchronous raid6 recovery routines for 2data and datap cases ]
      Cc: Yuri Tikhonov <yur@emcraft.com>
      Cc: Ilya Yanok <yanok@emcraft.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    • Dan Williams's avatar
      async_tx: add support for asynchronous GF multiplication · b2f46fd8
      Dan Williams authored
      [ Based on an original patch by Yuri Tikhonov ]
      This adds support for doing asynchronous GF multiplication by adding
      two additional functions to the async_tx API:
       async_gen_syndrome() does simultaneous XOR and Galois field
          multiplication of sources.
       async_syndrome_val() validates the given source buffers against known P
          and Q values.
      When a request is made to run async_pq against more than the hardware
      maximum number of supported sources we need to reuse the previous
      generated P and Q values as sources into the next operation.  Care must
      be taken to remove Q from P' and P from Q'.  For example to perform a 5
      source pq op with hardware that only supports 4 sources at a time the
      following approach is taken:
      p, q = PQ(src0, src1, src2, src3, COEF({01}, {02}, {04}, {08}))
      p', q' = PQ(p, q, q, src4, COEF({00}, {01}, {00}, {10}))
      p' = p + q + q + src4 = p + src4
      q' = {00}*p + {01}*q + {00}*q + {10}*src4 = q + {10}*src4
      Note: 4 is the minimum acceptable maxpq otherwise we punt to
      synchronous-software path.
      The DMA_PREP_CONTINUE flag indicates to the driver to reuse p and q as
      sources (in the above manner) and fill the remaining slots up to maxpq
      with the new sources/coefficients.
      Note1: Some devices have native support for P+Q continuation and can skip
      this extra work.  Devices with this capability can advertise it with
      dma_set_maxpq.  It is up to each driver how to handle the
      Note2: The api supports disabling the generation of P when generating Q,
      this is ignored by the synchronous path but is implemented by some dma
      devices to save unnecessary writes.  In this case the continuation
      algorithm is simplified to only reuse Q as a source.
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarYuri Tikhonov <yur@emcraft.com>
      Signed-off-by: default avatarIlya Yanok <yanok@emcraft.com>
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    • Dan Williams's avatar
      async_tx: remove walk of tx->parent chain in dma_wait_for_async_tx · 95475e57
      Dan Williams authored
      We currently walk the parent chain when waiting for a given tx to
      complete however this walk may race with the driver cleanup routine.
      The routines in async_raid6_recov.c may fall back to the synchronous
      path at any point so we need to be prepared to call async_tx_quiesce()
      (which calls  dma_wait_for_async_tx).  To remove the ->parent walk we
      guarantee that every time a dependency is attached ->issue_pending() is
      invoked, then we can simply poll the initial descriptor until
      This also allows for a lighter weight 'issue pending' implementation as
      there is no longer a requirement to iterate through all the channels'
      ->issue_pending() routines as long as operations have been submitted in
      an ordered chain.  async_tx_issue_pending() is added for this case.
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    • Dan Williams's avatar
      async_tx: add sum check flags · ad283ea4
      Dan Williams authored
      Replace the flat zero_sum_result with a collection of flags to contain
      the P (xor) zero-sum result, and the soon to be utilized Q (raid6 reed
      solomon syndrome) zero-sum result.  Use the SUM_CHECK_ namespace instead
      of DMA_ since these flags will be used on non-dma-zero-sum enabled
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
  6. 03 Jun, 2009 2 commits
    • Dan Williams's avatar
      async_tx: structify submission arguments, add scribble · a08abd8c
      Dan Williams authored
      Prepare the api for the arrival of a new parameter, 'scribble'.  This
      will allow callers to identify scratchpad memory for dma address or page
      address conversions.  As this adds yet another parameter, take this
      opportunity to convert the common submission parameters (flags,
      dependency, callback, and callback argument) into an object that is
      passed by reference.
      Also, take this opportunity to fix up the kerneldoc and add notes about
      the relevant ASYNC_TX_* flags for each routine.
      [ Impact: moves api pass-by-value parameters to a pass-by-reference struct ]
      Signed-off-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    • Dan Williams's avatar
      async_tx: kill ASYNC_TX_DEP_ACK flag · 88ba2aa5
      Dan Williams authored
      In support of inter-channel chaining async_tx utilizes an ack flag to
      gate whether a dependent operation can be chained to another.  While the
      flag is not set the chain can be considered open for appending.  Setting
      the ack flag closes the chain and flags the descriptor for garbage
      collection.  The ASYNC_TX_DEP_ACK flag essentially means "close the
      chain after adding this dependency".  Since each operation can only have
      one child the api now implicitly sets the ack flag at dependency
      submission time.  This removes an unnecessary management burden from
      clients of the api.
      [ Impact: clean up and enforce one dependency per operation ]
      Reviewed-by: default avatarAndre Noll <maan@systemlinux.org>
      Acked-by: default avatarMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
  7. 08 Apr, 2009 1 commit
  8. 25 Mar, 2009 1 commit
  9. 06 Jan, 2009 2 commits
  10. 18 Jul, 2008 2 commits
  11. 06 Feb, 2008 2 commits
  12. 20 Jul, 2007 1 commit
  13. 13 Jul, 2007 1 commit
    • Dan Williams's avatar
      async_tx: add the async_tx api · 9bc89cd8
      Dan Williams authored
      The async_tx api provides methods for describing a chain of asynchronous
      bulk memory transfers/transforms with support for inter-transactional
      dependencies.  It is implemented as a dmaengine client that smooths over
      the details of different hardware offload engine implementations.  Code
      that is written to the api can optimize for asynchronous operation and the
      api will fit the chain of operations to the available offload resources. 
      	I imagine that any piece of ADMA hardware would register with the
      	'async_*' subsystem, and a call to async_X would be routed as
      	appropriate, or be run in-line. - Neil Brown
      async_tx exploits the capabilities of struct dma_async_tx_descriptor to
      provide an api of the following general format:
      struct dma_async_tx_descriptor *
      async_<operation>(..., struct dma_async_tx_descriptor *depend_tx,
      			dma_async_tx_callback cb_fn, void *cb_param)
      	struct dma_chan *chan = async_tx_find_channel(depend_tx, <operation>);
      	struct dma_device *device = chan ? chan->device : NULL;
      	int int_en = cb_fn ? 1 : 0;
      	struct dma_async_tx_descriptor *tx = device ?
      		device->device_prep_dma_<operation>(chan, len, int_en) : NULL;
      	if (tx) { /* run <operation> asynchronously */
      		tx->tx_set_dest(addr, tx, index);
      		tx->tx_set_src(addr, tx, index);
      		async_tx_submit(chan, tx, flags, depend_tx, cb_fn, cb_param);
      	} else { /* run <operation> synchronously */
      		async_tx_sync_epilog(flags, depend_tx, cb_fn, cb_param);
      	return tx;
      async_tx_find_channel() returns a capable channel from its pool.  The
      channel pool is organized as a per-cpu array of channel pointers.  The
      async_tx_rebalance() routine is tasked with managing these arrays.  In the
      uniprocessor case async_tx_rebalance() tries to spread responsibility
      evenly over channels of similar capabilities.  For example if there are two
      copy+xor channels, one will handle copy operations and the other will
      handle xor.  In the SMP case async_tx_rebalance() attempts to spread the
      operations evenly over the cpus, e.g. cpu0 gets copy channel0 and xor
      channel0 while cpu1 gets copy channel 1 and xor channel 1.  When a
      dependency is specified async_tx_find_channel defaults to keeping the
      operation on the same channel.  A xor->copy->xor chain will stay on one
      channel if it supports both operation types, otherwise the transaction will
      transition between a copy and a xor resource.
      Currently the raid5 implementation in the MD raid456 driver has been
      converted to the async_tx api.  A driver for the offload engines on the
      Intel Xscale series of I/O processors, iop-adma, is provided in a later
      commit.  With the iop-adma driver and async_tx, raid456 is able to offload
      copy, xor, and xor-zero-sum operations to hardware engines.
      On iop342 tiobench showed higher throughput for sequential writes (20 - 30%
      improvement) and sequential reads to a degraded array (40 - 55%
      improvement).  For the other cases performance was roughly equal, +/- a few
      percentage points.  On a x86-smp platform the performance of the async_tx
      implementation (in synchronous mode) was also +/- a few percentage points
      of the original implementation.  According to 'top' on iop342 CPU
      utilization drops from ~50% to ~15% during a 'resync' while the speed
      according to /proc/mdstat doubles from ~25 MB/s to ~50 MB/s.
      The tiobench command line used for testing was: tiobench --size 2048
      --block 4096 --block 131072 --dir /mnt/raid --numruns 5
      * iop342 had 1GB of memory available
      * if CONFIG_DMA_ENGINE=n the asynchronous path is compiled away by making
        async_tx_find_channel a static inline routine that always returns NULL
      * when a callback is specified for a given transaction an interrupt will
        fire at operation completion time and the callback will occur in a
        tasklet.  if the the channel does not support interrupts then a live
        polling wait will be performed
      * the api is written as a dmaengine client that requests all available
      * In support of dependencies the api implicitly schedules channel-switch
        interrupts.  The interrupt triggers the cleanup tasklet which causes
        pending operations to be scheduled on the next channel
      * Xor engines treat an xor destination address differently than a software
        xor routine.  To the software routine the destination address is an implied
        source, whereas engines treat it as a write-only destination.  This patch
        modifies the xor_blocks routine to take a an explicit destination address
        to mirror the hardware.
      * fixed a leftover debug print
      * don't allow callbacks in async_interrupt_cond
      * fixed xor_block changes
      * fixed usage of ASYNC_TX_XOR_DROP_DEST
      * drop dma mapping methods, suggested by Chris Leech
      * printk warning fixups from Andrew Morton
      * don't use inline in C files, Adrian Bunk
      * select the API when MD is enabled
      * BUG_ON xor source counts <= 1
      * implicitly handle hardware concerns like channel switching and
        interrupts, Neil Brown
      * remove the per operation type list, and distribute operation capabilities
        evenly amongst the available channels
      * simplify async_tx_find_channel to optimize the fast path
      * introduce the channel_table_initialized flag to prevent early calls to
        the api
      * reorganize the code to mimic crypto
      * include mm.h as not all archs include it in dma-mapping.h
      * make the Kconfig options non-user visible, Adrian Bunk
      * move async_tx under crypto since it is meant as 'core' functionality, and
        the two may share algorithms in the future
      * move large inline functions into c files
      * checkpatch.pl fixes
      * gpl v2 only correction
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Acked-By: default avatarNeilBrown <neilb@suse.de>