On Thu, Mar 03, 2016 at 03:43:49PM +0000, Tvrtko Ursulin wrote: > > On 03/03/16 15:11, Chris Wilson wrote: > >On Thu, Mar 03, 2016 at 02:36:44PM +0000, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >> > >>Currently the wait_for_atomic_us only allows for a millisecond > >>granularity which is not nice towards callers requesting small > >>micro-second waits. > > > >Hmm, by granularity I think of the interval between COND reads. That > >should be the limiting factor in how fast we respond to the change in > >event (and so for the atomic variants should be virtually the same). > > Yeah not that granularity, should I say "timeout granularity" then > in the commit? Before if someone wanted to wait for, say 10us, it > would have busy looped for one jiffie instead. In the timeout > scenario that is. That is the headline improvement. "timeout granularity" would be much clearer > >Your suggestion that it is icache or similar is probably along the right > >path. A quick code size measurement of a test function would be a good > >supporting argument. > > I am not sure. It shaves ~3.3% (12 of original 353 bytes) of the > whole fw_domains_get which even if it is quite hot as you know, and > even 3% from the main loop in wait for atomic (3% here is a glorious > one byte). So I am not sure, but gem_latency results were quite > convincing. Unexplained for me. Ok. The small improvement in addition to stronger compile-time checks is certainly enough justification. The motivation is usually to avoid hitting the wait_for(register) loop in the first place, and a good mystery is always a good read for a rainy day. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
