lkml.org 
[lkml]   [2002]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2.5.43-mm2] New shared page table patch
Dave McCracken wrote:
>
> --On Tuesday, October 22, 2002 15:15:29 -0200 Rik van Riel
> <riel@conectiva.com.br> wrote:
>
> >> Or large pages. I confess to being a little perplexed as to
> >> why we're pursuing both.
> >
> > I guess that's due to two things.
> >
> > 1) shared pagetables can speed up fork()+exec() somewhat
> >
> > 2) if we have two options that fix the Oracle problem,
> > there's a better chance of getting at least one of
> > the two merged ;)
>
> 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?
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.079 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site