On Thu, Oct 26, 2017 at 12:04:11PM +0100, Chris Wilson wrote: > Quoting Michał Winiarski (2017-10-26 11:52:31) > > On Thu, Oct 26, 2017 at 08:31:27AM +0100, Chris Wilson wrote: > > > For measuring the cost of preemption, inject a low priority spinner > > > between the two measurements; the difference between the preemption and > > > the normal dispatch includes both the cost of the spinner dispatch and > > > of preempting it. Close enough for us to estimate the cost of > > > preemption, though we don't measure the cost of preemption on the local > > > ring! > > > > And as expected, we're seeing more delay with GuC, probably from worker > > scheduling delay (~2ms on my SKL if I'm reading the results correctly). > > Don't look at bxt then ;) Another order or magnitude. > > Most of that can be ascribed to using a worker, so we should be able to > pare it back somewhat. Just the idea that the GuC may take 10ms to > respond to a request is a bit disconcerting! Naively replacing send_mutex with spinlock brings us back into tens of microseconds range. > > Do we have to wait for the ack from the preempt request? Could we farm > that off to some other poor task? Then we would be in a position to > avoid that mutex and process-context worker. Oh well, you probably > already have ideas and plans for replacing that mutex :) > -Chris Error handling becomes more problematic (but doable... we're not doing anything that affects execution while waiting for preemption to complete). I was thinking about fast-path for preemption when it responds with a reasonable amount of time, with fallback to worker when it doesn't. -Michał _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
