Re: [PATCH] Prefaulting

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

Re: [PATCH] Prefaulting

--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

Re: [PATCH] Prefaulting

> >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

Re: [PATCH] Prefaulting

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

Re: [PATCH] Prefaulting

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

Re: [PATCH] Prefaulting

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/