RE: [PATCH 1/1] Implement shared page tables

2005-09-02 Thread Dave McCracken
--On Thursday, September 01, 2005 18:58:23 -0700 "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote: >> +prio_tree_iter_init(&iter, &mapping->i_mmap, >> +vma->vm_start, vma->vm_end); > > > I think this is a bug. The radix priority tree for address_space-> >

RE: [PATCH 1/1] Implement shared page tables

2005-09-01 Thread Chen, Kenneth W
Dave McCracken wrote on Tuesday, August 30, 2005 3:13 PM > This patch implements page table sharing for all shared memory regions that > span an entire page table page. It supports sharing at multiple page > levels, depending on the architecture. In function pt_share_pte(): > + while

RE: [PATCH 1/1] Implement shared page tables

2005-09-01 Thread Chen, Kenneth W
Dave McCracken wrote on Tuesday, August 30, 2005 3:13 PM > This patch implements page table sharing for all shared memory regions that > span an entire page table page. It supports sharing at multiple page > levels, depending on the architecture. > > > This version of the patch supports i386 and

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Dave McCracken
--On Wednesday, August 31, 2005 12:44:24 +0100 Hugh Dickins <[EMAIL PROTECTED]> wrote: > So you don't have Nick's test at the start of copy_page_range(): > if (!(vma->vm_flags & (VM_HUGETLB|VM_NONLINEAR|VM_RESERVED))) { > if (!vma->anon_vma) > return 0; >

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Martin J. Bligh
>> They're incompatible, but you could be left to choose one or the other >> via config option. > > Wouldn't need config option: there's /proc/sys/kernel/randomize_va_space > for the whole running system, compatibility check on the ELFs run, and > the infinite stack rlimit: enough ways to suppress

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Hugh Dickins
On Wed, 31 Aug 2005, Martin J. Bligh wrote: > --Hugh Dickins <[EMAIL PROTECTED]> wrote (on Wednesday, August 31, 2005 > 14:42:38 +0100): > > > > Which is indeed a further disincentive against shared page tables. > > Or shared pagetables a disincentive to randomizing the mmap space ;-) Fair poin

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Arjan van de Ven
> > Which is indeed a further disincentive against shared page tables. > > Or shared pagetables a disincentive to randomizing the mmap space ;-) > They're incompatible, but you could be left to choose one or the other > via config option. > > 3% on "a certain industry-standard database benchmark

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Martin J. Bligh
--Hugh Dickins <[EMAIL PROTECTED]> wrote (on Wednesday, August 31, 2005 14:42:38 +0100): > On Wed, 31 Aug 2005, Arjan van de Ven wrote: >> On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote: >> > I was going to say, doesn't randomize_va_space take away the rest of >> > the point? But no, it a

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Hugh Dickins
On Wed, 31 Aug 2005, Arjan van de Ven wrote: > On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote: > > I was going to say, doesn't randomize_va_space take away the rest of > > the point? But no, it appears "randomize_va_space", as it currently > > appears in mainline anyway, is somewhat an exag

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Arjan van de Ven
On Wed, 2005-08-31 at 12:44 +0100, Hugh Dickins wrote: > I was going to say, doesn't randomize_va_space take away the rest of > the point? But no, it appears "randomize_va_space", as it currently > appears in mainline anyway, is somewhat an exaggeration: it just shifts > the stack a little, with n

Re: [PATCH 1/1] Implement shared page tables

2005-08-31 Thread Hugh Dickins
On Tue, 30 Aug 2005, Dave McCracken wrote: > > This patch implements page table sharing for all shared memory regions that > span an entire page table page. It supports sharing at multiple page > levels, depending on the architecture. > > Performance testing has shown no degradation with this pa