Messages in this thread | | | From | "Chen, Kenneth W" <> | Subject | RE: 2.6.16 hugetlbfs problem - DEBUG_PAGEALLOC | Date | Fri, 24 Mar 2006 23:29:13 -0800 |
| |
Andrew Morton wrote on Friday, March 24, 2006 6:54 PM > "Chen, Kenneth W" <kenneth.w.chen@intel.com> wrote: > > > > Mark Rustad wrote on Friday, March 24, 2006 9:52 AM > > > I have narrowed this down to DEBUG_PAGEALLOC. If that option is > > > enabled, attempts to reference areas mmap-ed from hugetlbfs files > > > fault forever. You can see that I had that set in the failing config > > > I reported below. > > > > Yeah, it turns out that the debug option is not compatible with hugetlb > > page support. That debug option turns off PSE. Once it is turned off in > > CR4, cpu will ignore pse bit in the pmd and causing infinite page-not- > > present fault :-( > > I wonder if any of the other architectures which implement both these > features might have problems too.
Only 32-bit x86 arch implements both. We get away by not having DEBUG_PAGEALLOC feature on any other arch.
I read the ia32 processor manual, it says the pse flag in CR4 controls 4K/4M mapping in addition to pse bit in page directory entry. But in PAE mode, cr4.pse is ignored and pse bit in pmd controls 4K/2M mapping. I was going to verify that on my ia32 box, but apparently, turning on 64G highmem gives me machine reset at boot. (is it a known regression?)
X86-64 surly ignores cr4.pse for 4K/2M mapping. It is solely controlled by pse bit in pmd.
- Ken
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |