Messages in this thread | | | Date | Thu, 24 Oct 2002 06:50:43 -0400 (EDT) | From | Bill Davidsen <> | Subject | Re: [PATCH 2.5.43-mm2] New shared page table patch |
| |
On Tue, 22 Oct 2002, Dave McCracken wrote:
> > --On Tuesday, October 22, 2002 12:02:27 -0700 "Martin J. Bligh" > <mbligh@aracnet.com> wrote: > > > >Bill Davidsen wrote: > >> I'm just trying to decide what this might do for a news server with > >> hundreds of readers mmap()ing a GB history file. Benchmarks show the 2.5 > >> has more latency the 2.4, and this is likely to make that more obvious. > > > > On the other hand, I don't think shared pagetables have an mmap hook, > > though that'd be easy enough to add. And if you're not reading the whole > > history file, presumably the PTEs will only be sparsely instantiated > > anyway. > > Actually shared page tables work on any shared memory area, no matter how > it was created. When a page fault occurs and there's no pte page already > allocated (the common case for any newly mapped region) it checks the vma > to see if it's shared. If it's shared, it gets the address_space for that > vma, then walks through all the shared vmas looking for one that's mapped > at the same address and offset and already has a pte page that can be > shared.
That's more encouraging.
> So if your history file is mapped at the same address for all your > processes then it will use shared page tables. While it might be a nice > add-on to allow sharing if they're mapped on the same pte page boundary, > that doesn't seem likely enough to justify the extra work.
The reader processes are either forked (INN w/ daemon nnrpd) or pthreads (twister, earthquake, diablo). So everything will be the same.
Another thought, how does this play with NUMA systems? I don't have the problem, but presumably there are implications.
-- bill davidsen <davidsen@tmr.com> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.
- 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/
| |