On Fri, 11 Mar 2005, Andrew Morton wrote:
> > 200 MB allocation
> >
> > Mb Rep Thr CLine User System Wall flt/cpu/s fault/wsec
> > 200 31 10.02s 0.48s 0.05s860119.275 859918.989
> > 200 31 10.02s 0.46s 0.04s886129.730 886551.621
> > 200 31
--On Saturday, March 12, 2005 10:10:36 +0100 Arjan van de Ven <[EMAIL
PROTECTED]> wrote:
>
>> > From a quick peek it seems that the patch makes negligible difference for a
>> kernel compilation when prefaulting 1-2 pages and slows the workload down
>> quite a lot when prefaulting up to 16 page
> >From a quick peek it seems that the patch makes negligible difference for a
> kernel compilation when prefaulting 1-2 pages and slows the workload down
> quite a lot when prefaulting up to 16 pages.
well the last time I saw prefaulting experiments (Ingo was involved
iirc) the problem was that
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> There is even a slight performance win in the
> uniprocessor case:
>
> w/o any patch:
>
> Mb Rep Thr CLine User System Wall flt/cpu/s fault/wsec
> 200 31 10.01s 0.15s 0.01s846860.493 848882.424
> 200 31 1
On Fri, 11 Mar 2005, Andrew Morton wrote:
> > Results that show the impact of this patch are available at
> > http://oss.sgi.com/projects/page_fault_performance/
>
> There are a lot of numbers there. Was there an executive summary?
You are right there is none for prefaulting. What all of these p
Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> This patch allows to aggregate multiple page faults into a single one. It
> does that by detecting that an application generates a sequence of page
> faults.
>
> ...
> Results that show the impact of this patch are available at
> http://oss.sgi.com/
This patch allows to aggregate multiple page faults into a single one. It
does that by detecting that an application generates a sequence of page
faults.
If a fault occurred for page x and is then followed by page x+1 then it may
be reasonable to expect another page fault at x+2 in the future. If
7 matches
Mail list logo
