From patchwork Tue Aug 14 14:40:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tvrtko Ursulin X-Patchwork-Id: 10565751 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 24D1215A6 for ; Tue, 14 Aug 2018 14:41:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 176982A128 for ; Tue, 14 Aug 2018 14:41:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1575B2A11F; Tue, 14 Aug 2018 14:41:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 21BDF2A0E4 for ; Tue, 14 Aug 2018 14:41:07 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2A6E06E08D; Tue, 14 Aug 2018 14:41:06 +0000 (UTC) X-Original-To: Intel-gfx@lists.freedesktop.org Delivered-To: Intel-gfx@lists.freedesktop.org Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1B02C6E07C for ; Tue, 14 Aug 2018 14:41:05 +0000 (UTC) Received: by mail-wm0-x241.google.com with SMTP id o11-v6so12487806wmh.2 for ; Tue, 14 Aug 2018 07:41:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=gIdttn7VHg6sgxLlwfCSmpysaOAtkb6bvyVqqxn5TTk=; b=SAGRY08bwFKUG8aZvkfTVXvwjB45BpGP248CMk5Ib91EDe8eEkFZ93c1/csSbuDuiX TMSRfayYuiLDY9+wbrV5YBLpAJa1xp4l1ZhExWlorQAtPAK2f8jhBBx1ppC4Ue7vREUn gRe9YhCCnUIVHLeOIBymws6pYCCgAdTs8/dbJ0/Pt4qfd5Sp1FsJfZpEb3K6fqZHVRHo s4C5H8zmmaaXJUithICk47dBmLUxaJ3X9NAmnmDBPUI/fFeH6pYWZkyewrL+Q3ugMzwq QXibfv9bgbGL+zvELm27QS0k+eaEy4/jbrsZmupdXiaC8s+bIVFh4KgtIUQ+ALRszyDH 6pqw== X-Gm-Message-State: AOUpUlExRCIw+lB8a2nBxAy1RDgVAGtGEO0Auh6tXD4IFaU0wCEARvYY CtrGRIZVKpcHU2HtZrPWChPHA+8WSmA= X-Google-Smtp-Source: AA+uWPyluvBvuH3WUzZB0bUvv97ftIKoKuMb4vR0cSMezwyw3clzqFUWtCfHGjklMVE4tCYWjaQcAA== X-Received: by 2002:a1c:99c2:: with SMTP id b185-v6mr10276549wme.15.1534257663497; Tue, 14 Aug 2018 07:41:03 -0700 (PDT) Received: from localhost.localdomain ([95.144.165.93]) by smtp.gmail.com with ESMTPSA id w17-v6sm8884719wmc.43.2018.08.14.07.41.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 07:41:02 -0700 (PDT) From: Tvrtko Ursulin X-Google-Original-From: Tvrtko Ursulin To: Intel-gfx@lists.freedesktop.org Date: Tue, 14 Aug 2018 15:40:50 +0100 Message-Id: <20180814144058.19286-1-tvrtko.ursulin@linux.intel.com> X-Mailer: git-send-email 2.17.1 Subject: [Intel-gfx] [PATCH v10 0/8] Per context dynamic (sub)slice power-gating X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Virus-Scanned: ClamAV using ClamSMTP From: Tvrtko Ursulin Updated series after continuing Lionel's work. Userspace for the feature is the media-driver project on GitHub. Please see https://github.com/intel/media-driver/pull/271/commits. Headline changes: 1. No more master allow/disallow sysfs switch. Feature is unconditionally enabled for Gen11 and on other platforms it requires CAP_SYS_ADMIN. *** To be discussed if this is a good idea or not. *** 2. Two new patches due a) breaking out the global barrier, and b) fixing one GEM_BUG_ON regarding incorrent kernel context classification by i915_is_ggtt. Otherwise please see individial patch change logs. Main topic for the cover letter though is addressing the question of dynamic slice re-configuration performance impact. Introduction into this problem space is that changing the (sub)slice configuration has a cost at context switch time in the order of tens of milli- seconds. (It varies per Gen and with different slice count transitions.) So the question is whether a malicious unprivileged workload can negatively impact other clients. To try and answer this question I have extended gem_wsim and creating some test workloads. (Note that my testing was done on a Gen9 system. Overall message could be the same on Gen11 but needs to be verified.) First test was a simulated video playback client running in parallel with a simulated game of both medium and high complexity (uses around 60% or 90% of the render engine respectively, and 7% of the blitter engine). I had two flavours of the playback client, one which runs normally and one which requests reduced slice configuration. Both workloads are targetting to run at 60fps. Second test is the same but against a heavier simulated game workload, the one which uses around 90% of the render engine. Results are achieved frames per second as observed from the game client: No player Normal player SSEU enabled player Medium game 59.6 59.6 59.6 Heavy game 59.7 58.4 58.1 Here we can see that the medium workload was not affected either by the normal or SSEU player, while the heavy workload did see a performance hit. Both with the video player running in parallel, and slighlty larger when the player was SSEU enabled. Second test is running a malicious client (or clients) in parallel to the same simulated game workloads. These clients try to trigger many context switches by using multiple contexts with dependencies set up so request coalescing is defeated as much as possible. I tested both with normal and SSEU enabled malicious clients: DoS client SSEU DoS client Medium game 59.5 59.6 Heavy game 57.8 55.4 For here we can see a similar picture as with the first test. Medium game client is not affected by either DoS client, while the heavy game client is, more so with the SSEU enabled attacker. From both tests I think the conclusion is that dynamic SSEU switching does increase the magnitude of performance loss, especially with over-subscribed engines, due cost being proportional to context switch frequency. Likelyhood is that it slightly lowers the utilization level at which this starts to happen, but does not introduce a completely new vector of attack - that is - where it was possible to DoS a system from an unprivileged client, it still is. In both cases (SSEU enabled or not), a malicious client has the option to grind the system to a halt, albeit it may need fewer submission threads to do so when it is SSEU enabled. Chris Wilson (3): drm/i915: Program RPCS for Broadwell drm/i915: Record the sseu configuration per-context & engine drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin (3): drm/i915/perf: simplify configure all context function drm/i915/perf: reuse intel_lrc ctx regs macro drm/i915/perf: lock powergating configuration to default when active Tvrtko Ursulin (2): drm/i915: Add global barrier support drm/i915: Explicitly mark Global GTT address spaces drivers/gpu/drm/i915/i915_drv.h | 56 +++++++ drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_gem_context.c | 189 +++++++++++++++++++++++- drivers/gpu/drm/i915/i915_gem_context.h | 4 + drivers/gpu/drm/i915/i915_gem_gtt.c | 2 + drivers/gpu/drm/i915/i915_gem_gtt.h | 5 +- drivers/gpu/drm/i915/i915_perf.c | 68 +++++---- drivers/gpu/drm/i915/i915_request.c | 16 ++ drivers/gpu/drm/i915/i915_request.h | 10 ++ drivers/gpu/drm/i915/intel_lrc.c | 87 ++++++++--- drivers/gpu/drm/i915/intel_lrc.h | 3 + drivers/gpu/drm/i915/intel_ringbuffer.h | 4 + include/uapi/drm/i915_drm.h | 43 ++++++ 13 files changed, 439 insertions(+), 50 deletions(-)