On Wed, 2005-12-07 at 15:22 -0800, Badari Pulavarty wrote:
> BTW, the problem seems to be while dealing with shared memory areas
> that are backed by largepages.
I think this is likely not directly a sparsemem problem. It probably
just shows symptoms earlier.
See the attached patch. It attempts to detect and handle hugetlb pages
in the smaps code. However, I think one of the root issues here is that
bad_pmd() triggers for hugetlb pmds. I audited a few places where it is
called, and at least a couple of them can't have hugepages handed into
them, like fork().
-- Dave
---
proc-dups-dave/fs/proc/task_mmu.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+)
diff -puN fs/proc/task_mmu.c~task_mmu_fix fs/proc/task_mmu.c
--- proc-dups/fs/proc/task_mmu.c~task_mmu_fix 2005-12-07 16:34:38.000000000 -0800
+++ proc-dups-dave/fs/proc/task_mmu.c 2005-12-07 16:34:47.000000000 -0800
@@ -245,6 +245,28 @@ static inline void smaps_pmd_range(struc
pmd = pmd_offset(pud, addr);
do {
next = pmd_addr_end(addr, end);
+
+ if (pmd_huge(*pmd)) {
+ struct page *page;
+
+ page = follow_huge_pmd(vma->vm_mm, addr, pmd, 0);
+ if (!page)
+ continue;
+
+ mss->resident += HPAGE_SIZE;
+ if (page_count(page) >= 2) {
+ if (pte_dirty(*(pte_t *)pmd))
+ mss->shared_dirty += HPAGE_SIZE;
+ else
+ mss->shared_clean += HPAGE_SIZE;
+ } else {
+ if (pte_dirty(*(pte_t *)pmd))
+ mss->private_dirty += HPAGE_SIZE;
+ else
+ mss->private_clean += HPAGE_SIZE;
+ }
+ continue;
+ }
if (pmd_none_or_clear_bad(pmd))
continue;
smaps_pte_range(vma, pmd, addr, next, mss);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
