Re: Page fault scalability patch V18: Overview
On Mon, 7 Mar 2005, Darren Williams wrote: > Pid: 362, CPU 0, comm: kscrubd0 > psr : 121008022038 ifs : 8308 ip : [] > Not tainted > ip is at scrubd_rmpage+0x61/0x140 Would you try the new version on oss.sgi.com please. - 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: Page fault scalability patch V18: Overview
On Mon, 7 Mar 2005, Darren Williams wrote: Pid: 362, CPU 0, comm: kscrubd0 psr : 121008022038 ifs : 8308 ip : [a001000cf821] Not tainted ip is at scrubd_rmpage+0x61/0x140 Would you try the new version on oss.sgi.com please. - 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: Page fault scalability patch V18: Overview
Hi Christoph On Sun, 06 Mar 2005, Christoph Lameter wrote: > On Mon, 7 Mar 2005, Darren Williams wrote: > > > Hi Christoph > > > > On Fri, 04 Mar 2005, Christoph Lameter wrote: > > > > > Make sure that scrubd_stop on startup is set to 2 and no zero in > > > mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. > > > > > unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ > > > > This is the assignment when page zero fails. > > Could you just test this with the prezeroing patches alone? > Include a dmesg from a successful boot and then tell me what > you changed and where the boot failed. Which version of the patches did > you apply? > PATCHES: ftp://oss.sgi.com/projects/page_fault_performance/download/prezero/patch/patchset-2.6.11/ No scrubd_stop cat /proc/sys/vm/scrub_stop 2 /etc/sysctl.conf vm.scrub_stop=2 CONFIG_SCRUBD =N=Y Boots OK FAILED Oops of failed prezero boot: /dev/sdb4 has been mounted 31 times without being checked, check forced.Unable to handle kernel NULL pointer dereference (address )% kscrubd0[362]: Oops 11012296146944 [1] Pid: 362, CPU 0, comm: kscrubd0 psr : 121008022038 ifs : 8308 ip : []Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff4847277b8 f8 : 1003e1c07c8b4 f9 : 1003ec4367cec f10 : 10017a77079199649f035 f11 : 1003e014ee0f2 r1 : a00100a53d80 r2 : 00100100 r3 : e721fe04fdd0 r8 : 001008026038 r9 : e70020041070 r10 : 0008 r11 : 00200200 r12 : e721fe04fdc0 r13 : e721fe048000 r14 : r15 : fffd r16 : r17 : a0007fffabf48000 r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0002 r23 : r24 : r25 : r26 : r27 : 001008026038 r28 : e721fe04fdd0 r29 : a0007fffabf4a7e0 r30 : r31 : e70020041080 Call Trace: [] show_stack+0x80/0xa0 sp=e721fe04f980 bsp=e721fe049010 [] show_regs+0x7e0/0x800 sp=e721fe04fb50 bsp=e721fe048fa8 [] die+0x150/0x1c0 sp=e721fe04fb60 bsp=e721fe048f68 [] ia64_do_page_fault+0x370/0x980 sp=e721fe04fb60 bsp=e721fe048f00 [] ia64_leave_kernel+0x0/0x260 sp=e721fe04fbf0 bsp=e721fe048f00 [] scrubd_rmpage+0x60/0x140 sp=e721fe04fdc0 bsp=e721fe048ec0 [] zero_highest_order_page+0x120/0x2c0 sp=e721fe04fdc0 bsp=e721fe048e68 [] scrub_pgdat+0x110/0x1c0 sp=e721fe04fdd0 bsp=e721fe048e30 [] kscrubd+0x220/0x240 sp=e721fe04fdd0 bsp=e721fe048e00 [] kernel_thread_helper+0xd0/0x100 sp=e721fe04fe30 bsp=e721fe048dd0 [] start_kernel_thread+0x20/0x40 sp=e721fe04fe30 bsp=e721fe048dd0 <1>Unable to handle kernel NULL pointer dereference (address ) kscrubd1[363]: Oops 11012296146944 [2] Pid: 363, CPU 6, comm: kscrubd1 psr : 121008022018 ifs : 8308 ip : []Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff68a476010 f8 : 1003e1c87f85a f9 : 1003ec7b7ca76 f10 : 100188a47600ff75b89ff f11 : 1003e02291d80 r1 : a00100a53d80 r2 : 00100100 r3 : e741fe427dd0 r8 : 001008026018 r9 : e72510f0 r10 : 0008 r11 : 00200200 r12 : e741fe427dc0 r13 : e741fe42 r14 : r15 : fffd r16 : r17 : a0007fffc7ff r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0001 r23 : r24 : r25 : r26 : r27 : 001008026018 r28 : e741fe427dd0 r29 : a0007fffc7ff13f8 r30 : r31 : e7251100 Call Trace: [] show_stack+0x80/0xa0
Re: Page fault scalability patch V18: Overview
On Mon, 7 Mar 2005, Darren Williams wrote: > Hi Christoph > > On Fri, 04 Mar 2005, Christoph Lameter wrote: > > > Make sure that scrubd_stop on startup is set to 2 and no zero in > > mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. > > > unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ > > This is the assignment when page zero fails. Could you just test this with the prezeroing patches alone? Include a dmesg from a successful boot and then tell me what you changed and where the boot failed. Which version of the patches did you apply? - 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: Page fault scalability patch V18: Overview
Hi Christoph On Fri, 04 Mar 2005, Christoph Lameter wrote: > Make sure that scrubd_stop on startup is set to 2 and no zero in > mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. > unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ This is the assignment when page zero fails. Darren > On Fri, 4 Mar 2005, Darren Williams wrote: > > > Hi Darren > > > > On Fri, 04 Mar 2005, Darren Williams wrote: > > > > > Hi Christoph > > > > > > On Tue, 01 Mar 2005, Christoph Lameter wrote: > > > > > > > Is there any chance that this patchset could go into mm now? This has > > > > been > > > > discussed since last August > > > > > > > > Changelog: > > > > > > > > V17->V18 Rediff against 2.6.11-rc5-bk4 > > > > > > Just applied this patch against 2.6.11, however with the patch applied > > > and all the aditional config options not set, the kernel hangs at > > > Freeing unused kernel memory: 240kB freed > > > FYI: > > > > > > bootatomic prezero > > > OKon on > > > fail off on > > > fail off off > > > OKon off > > > > A bit extra info on the system: > > HP rx8620 Itanium(R) 2 16way > > > > > > > > > V16->V17 Do not increment page_count in do_wp_page. Performance data > > > > posted. > > > > V15->V16 of this patch: Redesign to allow full backback > > > > for architectures that do not supporting atomic operations. > > > > > > > > An introduction to what this patch does and a patch archive can be > > > > found on > > > > http://oss.sgi.com/projects/page_fault_performance. The archive also > > > > has the > > > > result of various performance tests (LMBench, Microbenchmark and > > > > kernel compiles). > > > > > > > > The basic approach in this patchset is the same as used in SGI's 2.4.X > > > > based kernels which have been in production use in ProPack 3 for a long > > > > time. > > > > > > > > The patchset is composed of 4 patches (and was tested against > > > > 2.6.11-rc5-bk4): > > > > > > > [SNIP] > > > > > > > - > > > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > > > > the body of a message to [EMAIL PROTECTED] > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- > > > Darren Williams > > > [EMAIL PROTECTED] > > > -- > > > - > > > 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/ > > -- > > Darren Williams > > [EMAIL PROTECTED] > > -- > > > - > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams [EMAIL PROTECTED] -- - 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: Page fault scalability patch V18: Overview
Hi Christoph On Fri, 04 Mar 2005, Christoph Lameter wrote: Make sure that scrubd_stop on startup is set to 2 and no zero in mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ This is the assignment when page zero fails. Darren On Fri, 4 Mar 2005, Darren Williams wrote: Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): [SNIP] - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: Page fault scalability patch V18: Overview
On Mon, 7 Mar 2005, Darren Williams wrote: Hi Christoph On Fri, 04 Mar 2005, Christoph Lameter wrote: Make sure that scrubd_stop on startup is set to 2 and no zero in mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ This is the assignment when page zero fails. Could you just test this with the prezeroing patches alone? Include a dmesg from a successful boot and then tell me what you changed and where the boot failed. Which version of the patches did you apply? - 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: Page fault scalability patch V18: Overview
Hi Christoph On Sun, 06 Mar 2005, Christoph Lameter wrote: On Mon, 7 Mar 2005, Darren Williams wrote: Hi Christoph On Fri, 04 Mar 2005, Christoph Lameter wrote: Make sure that scrubd_stop on startup is set to 2 and no zero in mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ This is the assignment when page zero fails. Could you just test this with the prezeroing patches alone? Include a dmesg from a successful boot and then tell me what you changed and where the boot failed. Which version of the patches did you apply? PATCHES: ftp://oss.sgi.com/projects/page_fault_performance/download/prezero/patch/patchset-2.6.11/ No scrubd_stop cat /proc/sys/vm/scrub_stop 2 /etc/sysctl.conf vm.scrub_stop=2 CONFIG_SCRUBD =N=Y Boots OK FAILED Oops of failed prezero boot: /dev/sdb4 has been mounted 31 times without being checked, check forced.Unable to handle kernel NULL pointer dereference (address )% kscrubd0[362]: Oops 11012296146944 [1] Pid: 362, CPU 0, comm: kscrubd0 psr : 121008022038 ifs : 8308 ip : [a001000cf821]Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff4847277b8 f8 : 1003e1c07c8b4 f9 : 1003ec4367cec f10 : 10017a77079199649f035 f11 : 1003e014ee0f2 r1 : a00100a53d80 r2 : 00100100 r3 : e721fe04fdd0 r8 : 001008026038 r9 : e70020041070 r10 : 0008 r11 : 00200200 r12 : e721fe04fdc0 r13 : e721fe048000 r14 : r15 : fffd r16 : r17 : a0007fffabf48000 r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0002 r23 : r24 : r25 : r26 : r27 : 001008026038 r28 : e721fe04fdd0 r29 : a0007fffabf4a7e0 r30 : r31 : e70020041080 Call Trace: [a001f3a0] show_stack+0x80/0xa0 sp=e721fe04f980 bsp=e721fe049010 [a001fc00] show_regs+0x7e0/0x800 sp=e721fe04fb50 bsp=e721fe048fa8 [a001000335f0] die+0x150/0x1c0 sp=e721fe04fb60 bsp=e721fe048f68 [a00100052430] ia64_do_page_fault+0x370/0x980 sp=e721fe04fb60 bsp=e721fe048f00 [a001a780] ia64_leave_kernel+0x0/0x260 sp=e721fe04fbf0 bsp=e721fe048f00 [a001000cf820] scrubd_rmpage+0x60/0x140 sp=e721fe04fdc0 bsp=e721fe048ec0 [a0010010e080] zero_highest_order_page+0x120/0x2c0 sp=e721fe04fdc0 bsp=e721fe048e68 [a0010010e330] scrub_pgdat+0x110/0x1c0 sp=e721fe04fdd0 bsp=e721fe048e30 [a0010010e600] kscrubd+0x220/0x240 sp=e721fe04fdd0 bsp=e721fe048e00 [a00100011410] kernel_thread_helper+0xd0/0x100 sp=e721fe04fe30 bsp=e721fe048dd0 [a00190e0] start_kernel_thread+0x20/0x40 sp=e721fe04fe30 bsp=e721fe048dd0 1Unable to handle kernel NULL pointer dereference (address ) kscrubd1[363]: Oops 11012296146944 [2] Pid: 363, CPU 6, comm: kscrubd1 psr : 121008022018 ifs : 8308 ip : [a001000cf821]Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff68a476010 f8 : 1003e1c87f85a f9 : 1003ec7b7ca76 f10 : 100188a47600ff75b89ff f11 : 1003e02291d80 r1 : a00100a53d80 r2 : 00100100 r3 : e741fe427dd0 r8 : 001008026018 r9 : e72510f0 r10 : 0008 r11 : 00200200 r12 : e741fe427dc0 r13 : e741fe42 r14 : r15 : fffd r16 : r17 : a0007fffc7ff r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0001 r23 : r24 : r25 : r26 : r27 :
Re: Page fault scalability patch V18: Overview
Make sure that scrubd_stop on startup is set to 2 and no zero in mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. On Fri, 4 Mar 2005, Darren Williams wrote: > Hi Darren > > On Fri, 04 Mar 2005, Darren Williams wrote: > > > Hi Christoph > > > > On Tue, 01 Mar 2005, Christoph Lameter wrote: > > > > > Is there any chance that this patchset could go into mm now? This has been > > > discussed since last August > > > > > > Changelog: > > > > > > V17->V18 Rediff against 2.6.11-rc5-bk4 > > > > Just applied this patch against 2.6.11, however with the patch applied > > and all the aditional config options not set, the kernel hangs at > > Freeing unused kernel memory: 240kB freed > > FYI: > > > > bootatomic prezero > > OKon on > > fail off on > > fail off off > > OKon off > > A bit extra info on the system: > HP rx8620 Itanium(R) 2 16way > > > > > > V16->V17 Do not increment page_count in do_wp_page. Performance data > > > posted. > > > V15->V16 of this patch: Redesign to allow full backback > > > for architectures that do not supporting atomic operations. > > > > > > An introduction to what this patch does and a patch archive can be found > > > on > > > http://oss.sgi.com/projects/page_fault_performance. The archive also has > > > the > > > result of various performance tests (LMBench, Microbenchmark and > > > kernel compiles). > > > > > > The basic approach in this patchset is the same as used in SGI's 2.4.X > > > based kernels which have been in production use in ProPack 3 for a long > > > time. > > > > > > The patchset is composed of 4 patches (and was tested against > > > 2.6.11-rc5-bk4): > > > > > [SNIP] > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > > Darren Williams > > [EMAIL PROTECTED] > > -- > > - > > 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/ > -- > Darren Williams > [EMAIL PROTECTED] > -- > - 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: Page fault scalability patch V18: Overview
Make sure that scrubd_stop on startup is set to 2 and no zero in mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. On Fri, 4 Mar 2005, Darren Williams wrote: Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): [SNIP] - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: Page fault scalability patch V18: Overview
Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: > Hi Christoph > > On Tue, 01 Mar 2005, Christoph Lameter wrote: > > > Is there any chance that this patchset could go into mm now? This has been > > discussed since last August > > > > Changelog: > > > > V17->V18 Rediff against 2.6.11-rc5-bk4 > > Just applied this patch against 2.6.11, however with the patch applied > and all the aditional config options not set, the kernel hangs at > Freeing unused kernel memory: 240kB freed > FYI: > > bootatomic prezero > OKon on > fail off on > fail off off > OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way > > > V16->V17 Do not increment page_count in do_wp_page. Performance data > > posted. > > V15->V16 of this patch: Redesign to allow full backback > > for architectures that do not supporting atomic operations. > > > > An introduction to what this patch does and a patch archive can be found on > > http://oss.sgi.com/projects/page_fault_performance. The archive also has the > > result of various performance tests (LMBench, Microbenchmark and > > kernel compiles). > > > > The basic approach in this patchset is the same as used in SGI's 2.4.X > > based kernels which have been in production use in ProPack 3 for a long > > time. > > > > The patchset is composed of 4 patches (and was tested against > > 2.6.11-rc5-bk4): > > > [SNIP] > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > Darren Williams > [EMAIL PROTECTED] > -- > - > 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/ -- Darren Williams [EMAIL PROTECTED] -- - 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: Page fault scalability patch V18: Overview
Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: > Is there any chance that this patchset could go into mm now? This has been > discussed since last August > > Changelog: > > V17->V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off > V16->V17 Do not increment page_count in do_wp_page. Performance data > posted. > V15->V16 of this patch: Redesign to allow full backback > for architectures that do not supporting atomic operations. > > An introduction to what this patch does and a patch archive can be found on > http://oss.sgi.com/projects/page_fault_performance. The archive also has the > result of various performance tests (LMBench, Microbenchmark and > kernel compiles). > > The basic approach in this patchset is the same as used in SGI's 2.4.X > based kernels which have been in production use in ProPack 3 for a long time. > > The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): > [SNIP] > - > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams [EMAIL PROTECTED] -- - 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: Page fault scalability patch V18: Overview
Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): [SNIP] - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: Page fault scalability patch V18: Overview
Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): [SNIP] - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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/
Page fault scalability patch V18: Overview
Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17->V18 Rediff against 2.6.11-rc5-bk4 V16->V17 Do not increment page_count in do_wp_page. Performance data posted. V15->V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): 1/4: ptep_cmpxchg and ptep_xchg to avoid intermittent zeroing of ptes The current way of synchronizing with the CPU or arch specific interrupts updating page table entries is to first set a pte to zero before writing a new value. This patch uses ptep_xchg and ptep_cmpxchg to avoid writing the zero for certain configurations. The patch introduces CONFIG_ATOMIC_TABLE_OPS that may be enabled as a experimental feature during kernel configuration if the hardware is able to support atomic operations and if an SMP kernel is being configured. A Kconfig update for i386, x86_64 and ia64 has been provided. On i386 this options is restricted to CPUs better than a 486 and non PAE mode (that way all the cmpxchg issues on old i386 CPUS and the problems with 64bit atomic operations on recent i386 CPUS are avoided). If CONFIG_ATOMIC_TABLE_OPS is not set then ptep_xchg and ptep_xcmpxchg are realized by falling back to clearing a pte before updating it. The patch does not change the use of mm->page_table_lock and the only performance improvement is the replacement of xchg-with-zero-and-then-write-new-pte-value with an xchg with the new value for SMP on some architectures if CONFIG_ATOMIC_TABLE_OPS is configured. It should not do anything major to VM operations. 2/4: Macros for mm counter manipulation There are various approaches to handling mm counters if the page_table_lock is no longer acquired. This patch defines macros in include/linux/sched.h to handle these counters and makes sure that these macros are used throughout the kernel to access and manipulate rss and anon_rss. There should be no change to the generated code as a result of this patch. 3/4: Drop the first use of the page_table_lock in handle_mm_fault The patch introduces two new functions: page_table_atomic_start(mm), page_table_atomic_stop(mm) that fall back to the use of the page_table_lock if CONFIG_ATOMIC_TABLE_OPS is not defined. If CONFIG_ATOMIC_TABLE_OPS is defined those functions may be used to prep the CPU for atomic table ops (i386 in PAE mode may f.e. get the MMX register ready for 64bit atomic ops) but are simply empty by default. Two operations may then be performed on the page table without acquiring the page table lock: a) updating access bits in pte b) anonymous read faults installed a mapping to the zero page. All counters are still protected with the page_table_lock thus avoiding any issues there. Some additional statistics are added to /proc/meminfo to give some statistics. Also counts spurious faults with no effect. There is a surprisingly high number of those on ia64 (used to populate the cpu caches with the pte??) 4/4: Drop the use of the page_table_lock in do_anonymous_page The second acquisition of the page_table_lock is removed from do_anonymous_page and allows the anonymous write fault to be possible without the page_table_lock. The macros for manipulating rss and anon_rss in include/linux/sched.h are changed if CONFIG_ATOMIC_TABLE_OPS is set to use atomic operations for rss and anon_rss (safest solution for now, other solutions may easily be implemented by changing those macros). This patch typically yield significant increases in page fault performance for threaded applications on SMP systems. - 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/
Page fault scalability patch V18: Overview
Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): 1/4: ptep_cmpxchg and ptep_xchg to avoid intermittent zeroing of ptes The current way of synchronizing with the CPU or arch specific interrupts updating page table entries is to first set a pte to zero before writing a new value. This patch uses ptep_xchg and ptep_cmpxchg to avoid writing the zero for certain configurations. The patch introduces CONFIG_ATOMIC_TABLE_OPS that may be enabled as a experimental feature during kernel configuration if the hardware is able to support atomic operations and if an SMP kernel is being configured. A Kconfig update for i386, x86_64 and ia64 has been provided. On i386 this options is restricted to CPUs better than a 486 and non PAE mode (that way all the cmpxchg issues on old i386 CPUS and the problems with 64bit atomic operations on recent i386 CPUS are avoided). If CONFIG_ATOMIC_TABLE_OPS is not set then ptep_xchg and ptep_xcmpxchg are realized by falling back to clearing a pte before updating it. The patch does not change the use of mm-page_table_lock and the only performance improvement is the replacement of xchg-with-zero-and-then-write-new-pte-value with an xchg with the new value for SMP on some architectures if CONFIG_ATOMIC_TABLE_OPS is configured. It should not do anything major to VM operations. 2/4: Macros for mm counter manipulation There are various approaches to handling mm counters if the page_table_lock is no longer acquired. This patch defines macros in include/linux/sched.h to handle these counters and makes sure that these macros are used throughout the kernel to access and manipulate rss and anon_rss. There should be no change to the generated code as a result of this patch. 3/4: Drop the first use of the page_table_lock in handle_mm_fault The patch introduces two new functions: page_table_atomic_start(mm), page_table_atomic_stop(mm) that fall back to the use of the page_table_lock if CONFIG_ATOMIC_TABLE_OPS is not defined. If CONFIG_ATOMIC_TABLE_OPS is defined those functions may be used to prep the CPU for atomic table ops (i386 in PAE mode may f.e. get the MMX register ready for 64bit atomic ops) but are simply empty by default. Two operations may then be performed on the page table without acquiring the page table lock: a) updating access bits in pte b) anonymous read faults installed a mapping to the zero page. All counters are still protected with the page_table_lock thus avoiding any issues there. Some additional statistics are added to /proc/meminfo to give some statistics. Also counts spurious faults with no effect. There is a surprisingly high number of those on ia64 (used to populate the cpu caches with the pte??) 4/4: Drop the use of the page_table_lock in do_anonymous_page The second acquisition of the page_table_lock is removed from do_anonymous_page and allows the anonymous write fault to be possible without the page_table_lock. The macros for manipulating rss and anon_rss in include/linux/sched.h are changed if CONFIG_ATOMIC_TABLE_OPS is set to use atomic operations for rss and anon_rss (safest solution for now, other solutions may easily be implemented by changing those macros). This patch typically yield significant increases in page fault performance for threaded applications on SMP systems. - 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/
