Re: [PATCH v2 00/25] AMDKFD kernel driver

[Jerome Glisse <j.glisse@gmail.com>]

On Mon, Jul 21, 2014 at 09:41:29PM +0300, Oded Gabbay wrote:
> On 21/07/14 21:22, Daniel Vetter wrote:
> > On Mon, Jul 21, 2014 at 7:28 PM, Oded Gabbay <oded.gabbay@amd.com> wrote:
> >>> I'm not sure whether we can do the same trick with the hw scheduler. But
> >>> then unpinning hw contexts will drain the pipeline anyway, so I guess we
> >>> can just stop feeding the hw scheduler until it runs dry. And then unpin
> >>> and evict.
> >> So, I'm afraid but we can't do this for AMD Kaveri because:
> > 
> > Well as long as you can drain the hw scheduler queue (and you can do
> > that, worst case you have to unmap all the doorbells and other stuff
> > to intercept further submission from userspace) you can evict stuff.
> 
> I can't drain the hw scheduler queue, as I can't do mid-wave preemption.
> Moreover, if I use the dequeue request register to preempt a queue
> during a dispatch it may be that some waves (wave groups actually) of
> the dispatch have not yet been created, and when I reactivate the mqd,
> they should be created but are not. However, this works fine if you use
> the HIQ. the CP ucode correctly saves and restores the state of an
> outstanding dispatch. I don't think we have access to the state from
> software at all, so it's not a bug, it is "as designed".
> 

I think here Daniel is suggesting to unmapp the doorbell page, and track
each write made by userspace to it and while unmapped wait for the gpu to
drain or use some kind of fence on a special queue. Once GPU is drain we
can move pinned buffer, then remap the doorbell and update it to the last
value written by userspace which will resume execution to the next job.

> > And if we don't want compute to be a denial of service on the display
> > side of the driver we need this ability. Now if you go through an
> > ioctl instead of the doorbell (I agree with Jerome here, the doorbell
> > should be supported by benchmarks on linux) this gets a bit easier,
> > but it's not a requirement really.
> > -Daniel
> > 
> On KV, we have the theoretical option of DOS on the display side as we
> can't do a mid-wave preemption. On CZ, we won't have this problem.
> 
> 	Oded

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>