Skip to contentSkip to conversation

Loss of PAT-WC after resume on i5

DISCUSSION H. Peter Anvin 2 participants 3 messages Jan 3, 2011 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

H. Peter Anvin

author
#1 lore raw
Quoted 18 lines · Chris Wilson

We have noticed that graphics may become very slow after suspend & resume. One effect that we have clearly identified is that writing through the GTT becomes very slow:

Before suspending:
Time to pwrite 16k through the CPU: 4µs
Time to read 16k through a GTT map: 901µs
Time to write 16k through a GTT map: 23µs
Time to read 16k (again) through a GTT map: 900µs
Time to pwrite 16k through the GTT: 7µs

After resume:
Time to pwrite 16k through the CPU: 4µs

  Time to read 16k through a GTT map:             900µs
  Time to write 16k through a GTT map:            876µs
  Time to read 16k (again) through a GTT map:     899µs
  Time to pwrite 16k through the GTT:             431µs
Quoted 7 lines

Presuming that it was the loss of the WC mapping, I tore down and recreated the ioremap_wc upon resume which restored performance back to normal.

So could we indeed be failing to restore the PAT caching state upon resume?

Sounds like it. It sounds based on your description that it's something more fundamental than just the state of the PAT MSR being lost, too, although perhaps that's the first thing to check...

-hpa

Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.
#2 lore raw
Quoted 3 lines · H. Peter Anvin

Sounds like it. It sounds based on your description that it's something more fundamental than just the state of the PAT MSR being lost, too, although perhaps that's the first thing to check...

Right, I should have mentioned that a rdmsr(MSR_ISA32_CR_PAT) showed no change across a dysfunctional resume. And that /sys/kernel/debug/x86/pat_memtype_list had the same contents (just the first entries reversed upon resume).
-Chris

Signature · 1 line
Chris Wilson, Intel Open Source Technology Centre
author
#3 lore raw
Quoted 9 lines · Chris Wilson
Quoted 3 lines · H. Peter Anvin

Sounds like it. It sounds based on your description that it's something more fundamental than just the state of the PAT MSR being lost, too, although perhaps that's the first thing to check...

Right, I should have mentioned that a rdmsr(MSR_ISA32_CR_PAT) showed no change across a dysfunctional resume. And that /sys/kernel/debug/x86/pat_memtype_list had the same contents (just the first entries reversed upon resume).

OK, this is doubly strange: both that entries would have change order and that they would not be active, if the PAT MSR is set correctly. That would imply that the page tables are somehow corrupt, which seems like a scary concept.

-hpa

Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.