* Chris Wilson wrote:
> > > A bisection pointed to
> > >
> > > commit ea8596bb2d8d37957f3e92db9511c50801689180
> > > Author: Masami Hiramatsu
> > > Date: Thu Jul 18 20:47:53 2013 +0900
> > >
> > > kprobes/x86: Remove unused text_poke_smp() and text_poke_smp_batch()
> > > functions
> >
* Andy Lutomirski wrote:
> On Wed, Nov 18, 2015 at 6:48 AM, Chris Wilson
> wrote:
> > Although
> >
> > diff --git a/include/linux/stop_machine.h b/include/linux/stop_machine.h
> > index d2abbdb..ff4f029 100644
> > --- a/include/linux/stop_machine.h
> > +++ b/include/linux/stop_machine.h
> > @@
On Wed, Nov 18, 2015 at 6:48 AM, Chris Wilson wrote:
> Although
>
> diff --git a/include/linux/stop_machine.h b/include/linux/stop_machine.h
> index d2abbdb..ff4f029 100644
> --- a/include/linux/stop_machine.h
> +++ b/include/linux/stop_machine.h
> @@ -97,7 +97,7 @@ static inline int try_stop_cpus
On Wed, Oct 08, 2014 at 05:10:59AM -0500, Chuck Ebbert wrote:
> On Wed, 8 Oct 2014 10:03:36 +0100
> Chris Wilson wrote:
>
> >
> > I ran into a problem on a Sandybridge i5-2500s whilst measuring the
> > performance of GTT write-combining access. I found subsequent runs were
> > about 10-40x slowe
On Thu, Oct 09, 2014 at 09:46:37AM -0500, Chuck Ebbert wrote:
> Well they're all the same.
>
> Hmm, x86info is not dumping all the variable MTRRs. You have 10, but
> it only prints the first 8. I don't know if it will show anything
> different, but can you try fixing it with this patch?
Source (h
On Thu, 9 Oct 2014 14:00:47 +0100
Chris Wilson wrote:
> On Thu, Oct 09, 2014 at 07:44:16AM -0500, Chuck Ebbert wrote:
> > Could you try installing x86info and running "x86info --mtrr
> > --all-cpus" while running the broken kernel?
>
> # /opt/xorg/src/intel-gpu-tools/tests/gem_gtt_speed
> IGT-V
On Thu, Oct 09, 2014 at 07:44:16AM -0500, Chuck Ebbert wrote:
> Could you try installing x86info and running "x86info --mtrr
> --all-cpus" while running the broken kernel?
# /opt/xorg/src/intel-gpu-tools/tests/gem_gtt_speed
IGT-Version: 1.8-g32a0308 (x86_64) (Linux: 3.17.0+ x86_64)
Time to read 1
On Thu, 9 Oct 2014 07:53:31 +0100
Chris Wilson wrote:
> # cat /proc/mtrr
> reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
> reg01: base=0x08000 ( 2048MB), size= 256MB, count=1: write-back
> reg02: base=0x08e00 ( 2272MB), size= 32MB, count=1: uncachable
> reg03: b
On Wed, Oct 08, 2014 at 02:36:49PM -0700, H. Peter Anvin wrote:
> On 10/08/2014 12:49 PM, Chris Wilson wrote:
> >
> > Indeed, this appears to be the explanation. (And here I thought PAT
> > superseded mtrrs - i915.ko stopped trying to use assign an mtrr for its
> > GTT quite a while ago.)
> >
> >
(2014/10/09 2:47), Chuck Ebbert wrote:
> On Wed, 8 Oct 2014 10:03:36 +0100
> Chris Wilson wrote:
>
>> and adding that back into the current build, e.g.
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 3632743..48a8a69 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@
On 10/08/2014 12:49 PM, Chris Wilson wrote:
>
> Indeed, this appears to be the explanation. (And here I thought PAT
> superseded mtrrs - i915.ko stopped trying to use assign an mtrr for its
> GTT quite a while ago.)
>
> Replacing the stop_machine there with on_each_cpu does the trick:
>
It shou
On Wed, Oct 08, 2014 at 05:10:59AM -0500, Chuck Ebbert wrote:
> On Wed, 8 Oct 2014 10:03:36 +0100
> Chris Wilson wrote:
>
> >
> > I ran into a problem on a Sandybridge i5-2500s whilst measuring the
> > performance of GTT write-combining access. I found subsequent runs were
> > about 10-40x slowe
On Wed, 8 Oct 2014 10:03:36 +0100
Chris Wilson wrote:
> and adding that back into the current build, e.g.
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 3632743..48a8a69 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -87,6 +87,7 @@ config X86
> select HAVE_US
On Wed, 8 Oct 2014 10:03:36 +0100
Chris Wilson wrote:
>
> I ran into a problem on a Sandybridge i5-2500s whilst measuring the
> performance of GTT write-combining access. I found subsequent runs were
> about 10-40x slower than the first. For example,
>
> igt/gem_gtt_speed:
>
> Time to read 16k
I ran into a problem on a Sandybridge i5-2500s whilst measuring the
performance of GTT write-combining access. I found subsequent runs were
about 10-40x slower than the first. For example,
igt/gem_gtt_speed:
Time to read 16k through a GTT map: 325.285µs
Time to write 16k through a GT
15 matches
Mail list logo