• Chris Wilson's avatar
    drm/i915: Load balancing across a virtual engine · 6d06779e
    Chris Wilson authored
    Having allowed the user to define a set of engines that they will want
    to only use, we go one step further and allow them to bind those engines
    into a single virtual instance. Submitting a batch to the virtual engine
    will then forward it to any one of the set in a manner as best to
    distribute load.  The virtual engine has a single timeline across all
    engines (it operates as a single queue), so it is not able to concurrently
    run batches across multiple engines by itself; that is left up to the user
    to submit multiple concurrent batches to multiple queues. Multiple users
    will be load balanced across the system.
    
    The mechanism used for load balancing in this patch is a late greedy
    balancer. When a request is ready for execution, it is added to each
    engine's queue, and when an engine is ready for its next request it
    claims it from the virtual engine. The first engine to do so, wins, i.e.
    the request is executed at the earliest opportunity (idle moment) in the
    system.
    
    As not all HW is created equal, the user is still able to skip the
    virtual engine and execute the batch on a specific engine, all within the
    same queue. It will then be executed in order on the correct engine,
    with execution on other virtual engines being moved away due to the load
    detection.
    
    A couple of areas for potential improvement left!
    
    - The virtual engine always take priority over equal-priority tasks.
    Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
    and hopefully the virtual and real engines are not then congested (i.e.
    all work is via virtual engines, or all work is to the real engine).
    
    - We require the breadcrumb irq around every virtual engine request. For
    normal engines, we eliminate the need for the slow round trip via
    interrupt by using the submit fence and queueing in order. For virtual
    engines, we have to allow any job to transfer to a new ring, and cannot
    coalesce the submissions, so require the completion fence instead,
    forcing the persistent use of interrupts.
    
    - We only drip feed single requests through each virtual engine and onto
    the physical engines, even if there was enough work to fill all ELSP,
    leaving small stalls with an idle CS event at the end of every request.
    Could we be greedy and fill both slots? Being lazy is virtuous for load
    distribution on less-than-full workloads though.
    
    Other areas of improvement are more general, such as reducing lock
    contention, reducing dispatch overhead, looking at direct submission
    rather than bouncing around tasklets etc.
    
    sseu: Lift the restriction to allow sseu to be reconfigured on virtual
    engines composed of RENDER_CLASS (rcs).
    
    v2: macroize check_user_mbz()
    v3: Cancel virtual engines on wedging
    v4: Commence commenting
    v5: Replace 64b sibling_mask with a list of class:instance
    v6: Drop the one-element array in the uabi
    v7: Assert it is an virtual engine in to_virtual_engine()
    v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
    
    Link: https://github.com/intel/media-driver/pull/283Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
    6d06779e
i915_gem.h 3.04 KB