Re: [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	imre.deak@intel.com, Intel-gfx@lists.freedesktop.org,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH 2/2] drm/i915: Use atomic waits for short non-atomic ones
Date: Tue, 28 Jun 2016 15:40:24 +0100	[thread overview]
Message-ID: <57728C58.9070700@linux.intel.com> (raw)
In-Reply-To: <20160628141447.GD28577@nuc-i3427.alporthouse.com>

On 28/06/16 15:14, Chris Wilson wrote:
> On Tue, Jun 28, 2016 at 02:55:28PM +0100, Chris Wilson wrote:
>> On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote:
>>> How would you implement it with cpu_clock? What would you do when
>>> re-scheduled?
>>
>> unsigned long base;
>> int cpu;
>> int ret;
>>
>> preempt_disable();
>> cpu = smp_processor_id();
>> base = local_clock() >> 10;
>> for (;;) {
>> 	u64 now = local_clock() >> 10;
>> 	preempt_enable();
>>
>> 	if (COND) {
>> 		ret = 0;
>> 		break;
>> 	}
>>
>> 	if (now - base >= timeout) {
>> 		ret = -ETIMEOUT;
>> 		break;
>> 	}
>> 	
>> 	cpu_relax();
>>
>> 	preempt_disable();
>> 	if (unlikely(cpu != smp_processor_id()) {
>> 		timeout -= now - base;
>
> For this, we should scale everything to ns (u64).

In other words not scale. Is this type of loop more preferable to you 
guys vs how it looked in this original patch?

Only difference is the preempt off section is shorter here, but I don't 
think that is interesting for the atomic waits case.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx