Messages in this thread | | | From | Gerrit Huizenga <> | Subject | Re: [PATCH 2.5.43-mm2] New shared page table patch | Date | Tue, 22 Oct 2002 12:06:29 -0700 |
| |
In message <3DB59DA7.453F89E2@digeo.com>, > : Andrew Morton writes: > Dave McCracken wrote: > > > > And > > 3) The current large page implementation is only for applications > > that want anonymous *non-pageable* shared memory. Shared page > > tables reduce resource usage for any shared area that's mapped > > at a common address and is large enough to span entire pte pages. > > Since all pte pages are shared on a COW basis at fork time, children > > will continue to share all large read-only areas with their > > parent, eg large executables. > > > > How important is that in practice? > > Seems that large pages are the preferred solution to the "Oracle > and DB2 use gobs of pagetable" problem because large pages also > reduce tlb reload traffic. > > So once that's out of the picture, what real-world, observed, > customers-are-hurting problem is solved by pagetable sharing?
If the shared pte patch had mmap support, then all shared libraries would benefit. Might need to align them to 4 MB boundaries for best results, which would also be easy for libraries with unspecified attach addresses (e.g. most shared libraries).
gerrit - 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/
| |