Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1430488

Introduce fences for N:M completion variables

Show all headers | View raw

struct completion allows for multiple waiters on a single event.
However, frequently we want to wait on multiple events. For example in
job processing, we need to wait for all prerequisite tasks to complete
before proceeding. Such dependency tracking is common to many situations.
In dma-buf, we already have a mechanism in place for tracking
dependencies between tasks and across drivers, the fence. Each fence is
a fixed point on a timeline that the hardware is processing (though the
hardware may be executing from multiple timelines concurrently). Each
fence may wait on any other fence (and for native fences the wait may be
executed on the device, but otherwise the signaling and forward progress
of the inter-fence serialisation is provided by the drivers themselves).
The added complexity of hardware interaction makes the dma-buf fence
unwieldy as a drop-in extension of struct completion. Enter kfence.

The kfence is intended to be as easy to use as a struct completion in
order to provide barriers in a DAG of tasks. It can provide
serialisation with other software events just as easily as it can mix in
dma-fences and be used to construct an event-driven state machine.

The tasks I have applied kfence to are:

 * providing fine-grained dependency and concurrent execution for the
   global initcalls. Drivers are currently creatively using the fixed
   initcall phases to solve dependency problems. Knowing which initcall
   can be executed in parallel helps speed up the boot process. Though
   not as much as removing the barrier after initramfs!

 * providing fine-grained dependency and concurrent execution for
   load/resume within a module (within the overall global async
   execution). Trying to parallelise a driver between discovery and
   hardware setup is hard to retrofit and will be challenging to
   maintain without a mechanism by which we can describe the dependencies
   of each phase upon each other (and hw state) and then let the
   hardware resolve the order in which to execute the phases. We want a
   declarative syntax?

 * providing asynchronous execution of GPU rendering (for a mix of
   inter-device rendering and inter-engine without hardware scheduling).
   This mixes dma-fences with an event-driven state machine. Here, the
   kfence primarily serves as a collection of dma-fences.

 * providing asynchronous execution of atomic modesetting,
   mixing the current usage of struct completion with dma-fences into
   one consistent framework 

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Introduce fences for N:M completion variables Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:10 +0200
  [PATCH 3/9] async: Extend kfence to allow struct embedding Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 8/9] async: Add execution barriers Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 2/9] async: Introduce kfence, a N:M completion mechanism Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 7/9] async: Add support for explicit fine-grained barriers Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 4/9] async: Extend kfences for listening on DMA fences Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 1/9] lib: Add kselftests for async-domains Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 5/9] async: Wrap hrtimer to provide a time source for a kfence Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 6/9] async: Add a convenience wrapper for waiting on implicit dma-buf Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200
  [PATCH 9/9] async: Introduce a dependency resolver for parallel execution Chris Wilson <chris@chris-wilson.co.uk> - 2016-06-24 11:20 +0200

csiph-web