Age | Commit message (Collapse) | Author |
|
Useful for comparing the cost of explict fences versus implicit.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
In theory, we need to only worry about concurrent mmio writes to the
same cacheline. So far, disabling the spinlock hasn't hung the machine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
When waiting for the producers to start, use the cond/mutex of the
Nth producer and not always the first.
Spotted-by: "Goel, Akash" <akash.goel@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Use a simpler statically allocated struct for computing the mean as
otherwise we many run out of memeory!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Well, 24000 years.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The joy of our hardware; don't let two threads attempt to read the same
register at the same time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Try and gauge the amount of CPU time used for each dispatch/wait cycle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow the producers to be set with maximum RT priority to verify that
the waiters are not exhibiting priorty-inversion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Reading BCS_TIMESTAMP just returns 0...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Try a different pattern to cascade the cancellation from producers to
their consumers in order to avoid one potential deadlock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Do the workload before the nop, so that if combining both, there is a
better chance for the spurious interrupts. Emit just one workload batch
(use the nops to generate spurious interrupts) and apply the factor to
the number of copies to make inside the workload - the intention is that
this gives sufficient time for all producers to run concurrently.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Just to make it easier to integrate into ezbench.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Split the distinct phases (generate interrupts, busywork, measure
latency) into separate batches for finer control.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow the user to choose a time to run for, default 10s
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Allow the user to select how many batches each producer submits before
waiting.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Knowing how long it takes to execute the workload (and how that scales)
is interesting to put the latency figures into perspective.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
Late last night I forgot I had only added the llc CPU mmaping and not
the !llc GTT mapping for byt/bsw.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
The goal is measure how long it takes for clients waiting on results to
wakeup after a buffer completes, and in doing so ensure scalibilty of
the kernel to large number of clients.
We spawn a number of producers. Each producer submits a busyload to the
system and records in the GPU the BCS timestamp of when the batch
completes. Then each producer spawns a number of waiters, who wait upon
the batch completion and measure the current BCS timestamp register and
compare against the recorded value.
By varying the number of producers and consumers, we can study different
aspects of the design, in particular how many wakeups the kernel does
for each interrupt (end of batch). The more wakeups on each batch, the
longer it takes for any one client to finish.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|