Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751995AbbKPNJ4 (ORCPT ); Mon, 16 Nov 2015 08:09:56 -0500 Received: from mga11.intel.com ([192.55.52.93]:33399 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099AbbKPNJz (ORCPT ); Mon, 16 Nov 2015 08:09:55 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,303,1444719600"; d="scan'208";a="601086164" Subject: Re: [PATCH 2/2] drm/i915: Limit the busy wait on requests to 2us not 10ms! To: Chris Wilson , Jens Axboe , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter , Eero Tamminen , "Rantala, Valtteri" , stable@kernel.vger.org References: <1447594364-4206-1-git-send-email-chris@chris-wilson.co.uk> <1447594364-4206-2-git-send-email-chris@chris-wilson.co.uk> <5649AEED.9090807@linux.intel.com> <20151116111208.GQ569@nuc-i3427.alporthouse.com> <5649C728.5040109@linux.intel.com> <20151116125537.GS569@nuc-i3427.alporthouse.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <5649D5A0.3080907@linux.intel.com> Date: Mon, 16 Nov 2015 13:09:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151116125537.GS569@nuc-i3427.alporthouse.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1409 Lines: 41 On 16/11/15 12:55, Chris Wilson wrote: > On Mon, Nov 16, 2015 at 12:08:08PM +0000, Tvrtko Ursulin wrote: >> >> On 16/11/15 11:12, Chris Wilson wrote: >>> On Mon, Nov 16, 2015 at 10:24:45AM +0000, Tvrtko Ursulin wrote: >>>> On 15/11/15 13:32, Chris Wilson wrote: >>>>> +static u64 local_clock_us(unsigned *cpu) >>>>> +{ >>>>> + u64 t; >>>>> + >>>>> + *cpu = get_cpu(); >>>>> + t = local_clock() >> 10; >>>> >>>> Needs comment I think to explicitly mention the approximation, or >>>> maybe drop the _us suffix? >>> >>> I did consider _approx_us but thought that was overkill. A comment along >>> the lines of >>> /* Approximately convert ns to us - the error is less than the >>> * truncation! >>> */ >> >> And the result is not used in subsequent calculations apart from >> comparing against an approximate timeout? > > Exactly, the timeout is fairly arbitrary and defined in the same units. > That we truncate is a much bigger cause for concern in terms of spinning > accurately for a definite length of time. Bah sorry that was not supposed to be a question but a suggestion to add to the comment. Must had mistyped the question mark. :) Regards, Tvrtko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/