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 10.01s 0.47s 0.04s887920.166 886855.775 > > But the system time went through the roof. Would that be accounting > inaccuracy? Redoing the test with 2.6.11.3-bk2 on AMD64(i386 mode) 1G Ram unpatched: Mb Rep Thr CLine User System Wall flt/cpu/s fault/wsec 200 31 10.00s 0.17s 0.01s844090.542 845814.978 200 31 10.00s 0.17s 0.01s853466.095 853376.002 200 31 10.00s 0.17s 0.01s853466.095 855138.626 200 31 10.00s 0.17s 0.01s848750.083 847934.815 200 31 10.00s 0.17s 0.01s848754.773 848248.554 200 31 10.00s 0.17s 0.01s844085.903 843914.312 200 31 10.01s 0.16s 0.01s848750.083 850573.694 200 31 10.00s 0.17s 0.01s844090.542 845451.843 prefault patch /proc/sys/vm/max_prealloc_order set to 4 Mb Rep Thr CLine User System Wall flt/cpu/s fault/wsec 200 31 10.00s 0.17s 0.01s848750.083 847902.050 200 31 10.00s 0.17s 0.01s853466.095 853565.693 200 31 10.00s 0.17s 0.01s848750.083 849595.115 200 31 10.00s 0.17s 0.01s848754.773 848628.162 200 31 10.00s 0.17s 0.01s844090.542 844554.657 200 31 10.00s 0.17s 0.01s848754.773 848590.654 200 31 10.00s 0.17s 0.01s848750.083 848792.295 200 31 10.00s 0.17s 0.01s844090.542 846406.904 Must have been something wrong with the test. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 pages. > > well the last time I saw prefaulting experiments (Ingo was involved > iirc) the problem was that the hitrate for the prefaults was such that > the costs for tearing down the extra redundant rmap chains was more > expensive than taking the "extra" faults. It seems linux has pretty > cheap faulting logic invalidating some of traditional OS assumptions... Yes - is pretty much exactly what I saw with this too, even if we only prefaulted up to 4 pages that were already in the pagecache. The additional cost in zap_pte_rage etc killed us, and it was wholly detrimental. I think we need better locality in glibc, etc before this is of much use. I had a debug patch somewhere to show how sparse the layout of ptes was, I'll see if I can find it. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 the hitrate for the prefaults was such that the costs for tearing down the extra redundant rmap chains was more expensive than taking the "extra" faults. It seems linux has pretty cheap faulting logic invalidating some of traditional OS assumptions... (fwiw one of the worst tests I remember was doing a lot of very short shell script executions; the case where bash lives briefly so that you get maximum cost for the extra teardowns while not a lot of bash gets run so prefaulting doesn't make a lot of difference) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 10.01s 0.16s 0.01s827724.160 830841.482 > 200 31 10.00s 0.16s 0.01s827724.160 827364.176 > > w/prefault patch > > 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 10.01s 0.47s 0.04s887920.166 886855.775 But the system time went through the roof. Would that be accounting inaccuracy? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 patches (prezero,atomic pte, prefault) have in common is that they improve performance for large number crunching applications but there is barely any improvement for kernel compiles and/or LMBench. The best I can do is insure that they do no harm. These issues are likely to become more pressing as memory sizes and appplication sizes grow. > >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. Yes. Prefaulting up to 16 pages slows the kernel compile down by 5% due to overallocating pages. > And for the uniprocessor "200 Megabyte allocation without prezeroing. > Single thread." workload it appears that the prefault patch slowed it down > by 4x. You likely compared the prezeroing performance with the prefaulting performance. Prezeroing yields a fourfold improvement gain: Mb Rep Thr CLine User System Wall flt/cpu/s fault/wsec 200 31 10.00s 0.02s 0.00s3756674.275 3712403.061 200 31 10.00s 0.03s 0.00s3488295.668 3501888.597 200 31 10.00s 0.03s 0.00s3407159.305 3420844.913 You need to compare the performance without any patches to the performance with the prefault patch. 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 10.01s 0.16s 0.01s827724.160 830841.482 200 31 10.00s 0.16s 0.01s827724.160 827364.176 w/prefault patch 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 10.01s 0.47s 0.04s887920.166 886855.775 > Am I misreading the results? If not, it's a bit disappointing. Yes. The prefault patch actually improves UP performance of the Microbenchmark slightly. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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/projects/page_fault_performance/ There are a lot of numbers there. Was there an executive summary? >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. And for the uniprocessor "200 Megabyte allocation without prezeroing. Single thread." workload it appears that the prefault patch slowed it down by 4x. Am I misreading the results? If not, it's a bit disappointing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
