Re: [PATCH/RFC] Shared page tables

From: Dave McCracken
Date: Mon Jan 23 2006 - 19:17:52 EST




--On Monday, January 23, 2006 17:58:08 -0600 Ray Bryant
<raybry@xxxxxxxxxxxxxxxxx> wrote:

> Like Robin, I would appreciate a test application, or at least a
> description of how to write one, or some other trick to figure out if
> this is working.

My apologies. I do have a small test program and intended to clean it up
to send to Robin, but got sidetracked (it's fugly at the moment). I'll see
about getting it a bit more presentable.

> I scanned through this thread looking for a test application, and didn't
> see one. Is it sufficient just to create a large shared read-only
> mmap'd file and share it across a bunch of process to get this code
> invoked? How large of a file is needed (on x86_64), assuming that we
> just turn on the pte level of sharing? And what kind of alignment
> constraints do we end up under in order to make the sharing happen?
> (My guess would be that there aren't any such constraints (well, page
> alignment.. :-) if we are just sharing pte's.)

The basic rule for pte sharing is that some portion of a memory region must
span an entire pte page. For i386 and x96_64 that would be 2 meg. The
region must either be read-only or marked to be shared if it is writeable.

The code does opportunistically look for any pte page that is fully within
a shareable vma, and will share if it finds one.

Oh, and one more caveat. The region must be mapped to the same address in
each process.

> I turned on the PT_DEBUG stuff, but thus far have found no evidence of
> pte sharing actually occurring in a normal system boot. I'm surprised
> by that as I (naively?) would have expected shared libraries to use
> shared ptes.

Most system software, including the shared libraries, don't have any
regions that are big enough for sharing (the text section for libc, for
example, is about 1.5 meg).

Dave McCracken

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/