Hi!
Do we somehow need to clarify in the headers the semantics for this?
From my understanding when discussing the CCS migration series with
Ram, the kernel will never do any resolving (compressing /
decompressing) migrations or evictions which basically implies the
following:
*) Compressed
Quoting Thomas Hellström (2022-03-16 09:25:16)
> Hi!
>
> Do we somehow need to clarify in the headers the semantics for this?
>
> From my understanding when discussing the CCS migration series with
> Ram, the kernel will never do any resolving (compressing /
> decompressing) migrations or evic
On 17/03/2022 08:43, Joonas Lahtinen wrote:
Quoting Thomas Hellström (2022-03-16 09:25:16)
Hi!
Do we somehow need to clarify in the headers the semantics for this?
From my understanding when discussing the CCS migration series with
Ram, the kernel will never do any resolving (compressing /
d
On Thu, 2022-03-17 at 10:43 +0200, Joonas Lahtinen wrote:
> Quoting Thomas Hellström (2022-03-16 09:25:16)
> > Hi!
> >
> > Do we somehow need to clarify in the headers the semantics for
> > this?
> >
> > From my understanding when discussing the CCS migration series
> > with
> > Ram, the kernel
+@Vetter, Daniel
Let's not start re-inventing this on the fly again. That's how we got into
trouble in the past. The SAS/Whitepaper does currently require the SMEM+LMEM
placement for mappable, for good reasons.
We cannot 'always migrate to mappable in the fault handler'. Or at least, this
is n
Hi,
On Thu, 2022-03-17 at 18:21 +, Bloomfield, Jon wrote:
> +@Vetter, Daniel
>
> Let's not start re-inventing this on the fly again. That's how we got
> into trouble in the past. The SAS/Whitepaper does currently require
> the SMEM+LMEM placement for mappable, for good reasons.
Just to avoid
@Thomas Hellström - I agree :-)
My question was really to @Joonas Lahtinen, who was saying we could always
migrate in the CPU fault handler. I am pushing back on that unless we have no
choice. It's the very complication we were trying to avoid with the current
SAS. If that's what's needed, then
Maybe also good to add dri-devel to these discussions.
I'm not sure where exactly we landed with dgpu error capture (maybe I
should check the code but it's really w/e here), but I think we can
also toss in "you need a non-recoverable context for error capture to
work on dgpu". Since that simplifie
On 3/18/22 19:12, Daniel Vetter wrote:
Maybe also good to add dri-devel to these discussions.
I'm not sure where exactly we landed with dgpu error capture (maybe I
should check the code but it's really w/e here), but I think we can
also toss in "you need a non-recoverable context for error cap
On 18/03/2022 18:12, Daniel Vetter wrote:
Maybe also good to add dri-devel to these discussions.
I'm not sure where exactly we landed with dgpu error capture (maybe I
should check the code but it's really w/e here), but I think we can
also toss in "you need a non-recoverable context for error ca
On Thu, 2022-03-31 at 10:25 +0100, Matthew Auld wrote:
> On 18/03/2022 18:12, Daniel Vetter wrote:
> > Maybe also good to add dri-devel to these discussions.
> >
> > I'm not sure where exactly we landed with dgpu error capture (maybe
> > I
> > should check the code but it's really w/e here), but I
11 matches
Mail list logo
