I've gotten my PAT code working on my PIII boxen here.  It seems to be 
reasonable stable for me.  I'd appreciate it if the individuals 
interested in per page write combining would take a look at it.  I've 
only included initialization code for the AMD and Intel processors. 
This patch replaces the write through cache type with the write 
combining cache type (pgprot value of _PAGE_PWT only.)  It looks like 
from the code in the main kernel tree that this change wouldn't affect 
any drivers or core kernel code.

I've included PAT-Jan-26.patch.gz (against 2.4.0 proper), and 
testpat.c.gz to this message.  After you've patched/installed your 
kernel, compile testpat.c as a module (example command line: gcc -O2 
-DMODULE -D__KERNEL__ -c testpat.c), and insmod it.  It should fail with 
ENOMEM, and print out some simple benchmarks into your kernel log.

I'd appreciate any help people can give me in testing, and any comments 
on the API that I plan to expose.

I've also included a rough TODO list and the open questions that I have 
currently.

-Jeff

TODO list before submission to 2.5:
1. API cleanup: pat_wrtcomb_vmalloc_page_list takes num_pages as an 
argument, it should just take a size in bytes.
2. Convert page mappings back to 4MB when memory is freed
3. Testing on a variety of AMD Athlon systems (untested currently)
4. Testing on a variety of PIII systems (tested on PIII Xeon 800)
5. Make sure I didn't break SMP support during debugging (my SMP PIII 
box is temporarily unavailable.)
6. Possibly provide a mechanism for someone to convert an already 
allocated page or page_list to use the write combining cache type.

Open questions:
1. Should struct page_list contain an array of virtual addresses or 
struct page?  (Currently its virtual addresses)
2. Should the page table management routines (convert_4mb_to_individual 
and convert_individual_to_4mb_page) be exported to modules?