Bug 12801

Summary:	x86-pat optimizaitions.
Product:	Platform Specific/Hardware	Reporter:	Thomas Hellstrom (thellstrom)
Component:	x86-64	Assignee:	platform_i386
Status:	RESOLVED OBSOLETE
Severity:	enhancement	CC:	alan
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.31 rc series	Subsystem:
Regression:	No	Bisected commit-id:

Description Thomas Hellstrom 2009-03-02 01:51:30 UTC

The x86 PAT code keeps track of caching attributes for 
IO memory regions and RAM pages differently. Normal RAM pages are tracked using data in struct page entries.

To determine whether code is IO memory or RAM a rather elaborate search is done, which may be somewhat expensive.

The core linux mm kernel code uses pfn_valid() to determine whether there is a backing struct_page entry or not. My humble suggestion is that the PAT code would use the same test, and avoids calling track_pfn_vma_new() if pfn_valid() is true.

Also, it would be nice to see a track_pfn_vma_new() fatpath from vm_insert_pfn / vm_insert_mixed() in the calse pfn_valid() is false.

Comment 1 Thomas Hellstrom 2009-07-31 09:12:28 UTC

Ping.

I'm currently debugging a case where I think the current RAM test apparently fails on an Athlon64 system (x86_64)

Changing caching policy for 3D textures (normal pages using the set_pages_uc interface) is extremely slow and oprofile is showing reserve_memtype / free_memtype as the main CPU users (more than 95% of samples)

When the app is killed, about 500MB of memory is about to be transitioned back to wb. That takes well over 1 minute. Again, free_memtype is taking more than 95% of the time. 

I'm guessing this is becuse the ram test fails and the PAT code sets up lists of pfn regions with non-standard caching attributes.

I can't reproduce this on an intel 32-bit system, but the fact that this is now a real problem that should affect also "traditional" AGP, I'm raising the importance of this bug.

Comment 2 Thomas Hellstrom 2009-07-31 13:43:54 UTC

Hmm.

I might have spoken too early here. The symptoms may be related to
bug #13884 just opened.

I can test later. If that turns out to be the case I'll lower the importance of this bug again.

Comment 3 Thomas Hellstrom 2009-08-03 12:27:47 UTC

The x86_64 problems were indeed caused by bug #13884. The use of virtual- instead of physical page addresses caused the memtype tracking code to assume the pages were outside of normal ram, making the reserved memory region list in the pat code excessively large.

Since bug #13884 is fixed, I'm lowering the importance of this bug again.

Comment 4 Alan 2012-05-30 14:20:54 UTC

Closing out obsolete stale bugs, if this is incorrect please re-open