On Mon, Jul 15, 2019 at 04:10:36PM -0700, Andy Lutomirski wrote:
> On Mon, Jul 15, 2019 at 3:53 PM Andi Kleen wrote:
> >
> > > I haven't tested on a real kernel with i915. Does i915 really hit
> > > this code path? Does it happen more than once or twice at boot?
> >
> > Yes some workloads alloca
On Mon, Jul 15, 2019 at 3:53 PM Andi Kleen wrote:
>
> > I haven't tested on a real kernel with i915. Does i915 really hit
> > this code path? Does it happen more than once or twice at boot?
>
> Yes some workloads allocate/free a lot of write combined memory
> for graphics objects.
>
But where d
> I haven't tested on a real kernel with i915. Does i915 really hit
> this code path? Does it happen more than once or twice at boot?
Yes some workloads allocate/free a lot of write combined memory
for graphics objects.
-Andi
On Mon, Jul 15, 2019 at 12:38 PM Andi Kleen wrote:
>
> >
> > That does not answer the question whether it's worthwhile to do that.
>
> It's likely worthwhile for (Intel integrated) graphics.
>
> There was also a recent issue with 3dxp/dax, which uses ioremap in some
> cases.
>
FWIW, I applied th
On Mon, 15 Jul 2019, Andi Kleen wrote:
> > Right, we don't know where the PAT invocation comes from and whether they
> > are safe to omit flushing the cache. The module load code would be one
> > obvious candidate.
>
> Module load just changes the writable/executable status, right? That shouldn't
On Mon, Jul 15, 2019 at 12:39 PM Andi Kleen wrote:
>
> > Right, we don't know where the PAT invocation comes from and whether they
> > are safe to omit flushing the cache. The module load code would be one
> > obvious candidate.
>
> Module load just changes the writable/executable status, right? T
> Right, we don't know where the PAT invocation comes from and whether they
> are safe to omit flushing the cache. The module load code would be one
> obvious candidate.
Module load just changes the writable/executable status, right? That shouldn't
need to flush in any case because it doesn't chan
>
> That does not answer the question whether it's worthwhile to do that.
It's likely worthwhile for (Intel integrated) graphics.
There was also a recent issue with 3dxp/dax, which uses ioremap in some
cases.
-Andi
On Mon, 15 Jul 2019, Uros Bizjak wrote:
> On Mon, Jul 15, 2019 at 8:41 PM Thomas Gleixner wrote:
> >
> > On Mon, 15 Jul 2019, Andi Kleen wrote:
> > > Uros Bizjak writes:
> > >
> > > > Recent patch [1] disabled a self-snoop feature on a list of processor
> > > > models with a known errata, so we a
On Mon, Jul 15, 2019 at 8:41 PM Thomas Gleixner wrote:
>
> On Mon, 15 Jul 2019, Andi Kleen wrote:
> > Uros Bizjak writes:
> >
> > > Recent patch [1] disabled a self-snoop feature on a list of processor
> > > models with a known errata, so we are confident that the feature
> > > should work on rem
On Mon, 15 Jul 2019, Andi Kleen wrote:
> Uros Bizjak writes:
>
> > Recent patch [1] disabled a self-snoop feature on a list of processor
> > models with a known errata, so we are confident that the feature
> > should work on remaining models also for other purposes than to speed
> > up MTRR progr
Uros Bizjak writes:
> Recent patch [1] disabled a self-snoop feature on a list of processor
> models with a known errata, so we are confident that the feature
> should work on remaining models also for other purposes than to speed
> up MTRR programming.
MTRR is very different than TLBs.
>From m
On Mon, Jul 15, 2019 at 10:24 AM Thomas Gleixner wrote:
>
> Uros,
>
> On Thu, 11 Jul 2019, Uros Bizjak wrote:
> > Recent patch [1] disabled a self-snoop feature on a list of processor
> > models with a known errata, so we are confident that the feature
> > should work on remaining models also for
Uros,
On Thu, 11 Jul 2019, Uros Bizjak wrote:
> Recent patch [1] disabled a self-snoop feature on a list of processor
> models with a known errata, so we are confident that the feature
> should work on remaining models also for other purposes than to speed
> up MTRR programming.
>
> I would like
On Thu, Jul 11, 2019 at 4:39 PM Andy Lutomirski wrote:
>
> On Thu, Jul 11, 2019 at 1:13 AM Uros Bizjak wrote:
> >
> > Recent patch [1] disabled a self-snoop feature on a list of processor
> > models with a known errata, so we are confident that the feature
> > should work on remaining models also
On Thu, Jul 11, 2019 at 1:13 AM Uros Bizjak wrote:
>
> Recent patch [1] disabled a self-snoop feature on a list of processor
> models with a known errata, so we are confident that the feature
> should work on remaining models also for other purposes than to speed
> up MTRR programming.
>
> I would
Recent patch [1] disabled a self-snoop feature on a list of processor
models with a known errata, so we are confident that the feature
should work on remaining models also for other purposes than to speed
up MTRR programming.
I would like to resurrect an old patch [2] that avoids calling clflush
a
17 matches
Mail list logo
