From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: Re: [PATCH] drm/i915: Use hash tables for the command
 parser
Date: Mon, 12 May 2014 15:49:02 +0100
Message-ID: <5370DF5E.5020808@linux.intel.com>
References: <1399756243-30974-1-git-send-email-bradley.d.volkin@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by gabe.freedesktop.org (Postfix) with ESMTP id 023E96E704
 for <intel-gfx@lists.freedesktop.org>; Mon, 12 May 2014 07:49:04 -0700 (PDT)
In-Reply-To: <1399756243-30974-1-git-send-email-bradley.d.volkin@intel.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
 <mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: bradley.d.volkin@intel.com, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org


On 05/10/2014 10:10 PM, bradley.d.volkin@intel.com wrote:
> From: Brad Volkin <bradley.d.volkin@intel.com>
>
> For clients that submit large batch buffers the command parser has
> a substantial impact on performance. On my HSW ULT system performance
> drops as much as ~20% on some tests. Most of the time is spent in the
> command lookup code. Converting that from the current naive search to
> a hash table lookup reduces the performance drop to ~10%.
>
> The choice of value for I915_CMD_HASH_ORDER allows all commands
> currently used in the parser tables to hash to their own bucket (except
> for one collision on the render ring). The tradeoff is that it wastes
> memory. Because the opcodes for the commands in the tables are not
> particularly well distributed, reducing the order still leaves many
> buckets empty. The increased collisions don't seem to have a huge
> impact on the performance gain, but for now anyhow, the parser trades
> memory for performance.
>
> NB: Ville noticed that the error paths through the ring init code
> will leak memory. I've not addressed that here. We can do a follow
> up pass to handle all of the leaks.
>
> v2: improved comment describing selection of hash key mask (Damien)
> replace a BUG_ON() with an error return (Tvrtko, Ville)
> commit message improvements
>
> Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Regards,

Tvrtko