From owner-freebsd-arch@FreeBSD.ORG Thu Jan 1 02:17:02 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF05A16A4CE; Thu, 1 Jan 2004 02:17:02 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5A9C43D4C; Thu, 1 Jan 2004 02:17:00 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) i01AGclM096085; Thu, 1 Jan 2004 10:16:39 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: "M. Warner Losh" In-Reply-To: <20031231.132536.38326387.imp@bsdimp.com> References: <20031231185358.66023.qmail@web14812.mail.yahoo.com> <20031231.132536.38326387.imp@bsdimp.com> Content-Type: text/plain Message-Id: <1072952198.3233.24.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 01 Jan 2004 10:16:38 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on herring.nlsystems.com cc: rosti_bsd@yahoo.com cc: freebsd-arch@freebsd.org Subject: Re: IRQ 2 problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2004 10:17:03 -0000 On Wed, 2003-12-31 at 20:25, M. Warner Losh wrote: > In message: > John Baldwin writes: > : > : On 31-Dec-2003 Rostislav Krasny wrote: > : > --- "M. Warner Losh" wrote: > : >> In message: <20031230.190927.108191769.imp@bsdimp.com> > : >> "M. Warner Losh" writes: > : >> : The reason that it iasn't been committed is because it is > : >> incorrect. > : >> : > : >> : > : >> > : > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=15473+0+archive/2003/freebsd-arch/20030831.freebsd-ar > : > ch > : >> : > : >> : has the particulars. > : >> > : >> Does your machine have an APIC? My laptop doesn't seem to exhibit > : >> the problem. > : > > : > No, it doesn't seem to have an APIC. This is Pentium MMX 200MHz machine > : > based on Intel's 430TX chipset. > : > > : > What is the correct way to fix this IRQ 2 problem? I can help to test it. > : > : IRQ 2 in FreeBSD is spelled IRQ 9. If a PNP device wants to use IRQ 2, it > : can be set to IRQ 2 in hardware, but it must use IRQ 9 when doing the > : bus_alloc_resource() and bus_setup_intr(). > > Actually the problem appears to be that the hardware wants 9 too. '2' > shouldn't be used at all, nor given out in allocation when we're using > AT PIC because that's the chaining IRQ. That's the current problem. > Eg, the isa bus is handing out '2' when it has no buisness doing so. The original fix for this which has been lost over the years was to exclude IRQ2 from the set of available interrupts. When the PnP code attempted to allocate an irq for the device, it would try for 2, not get it and settle for 9. At some point, IRQ2 was added back into the set but the PIC driver was fixed to allocate IRQ2 itself as early as possible. This matches the way the hardware is wired together and has a certain 'rightness' to it. Unfortunately the PIC driver doesn't seem to allocate IRQ2 for itself any more which makes it available for broken PnP devices. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 1 02:35:11 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B92D416A4CE; Thu, 1 Jan 2004 02:35:11 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26E9243D4C; Thu, 1 Jan 2004 02:35:07 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i01AZ3AI018512; Thu, 1 Jan 2004 03:35:03 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 01 Jan 2004 03:34:44 -0700 (MST) Message-Id: <20040101.033444.103565788.imp@bsdimp.com> To: dfr@nlsystems.com From: "M. Warner Losh" In-Reply-To: <1072952198.3233.24.camel@herring.nlsystems.com> References: <20031231.132536.38326387.imp@bsdimp.com> <1072952198.3233.24.camel@herring.nlsystems.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: rosti_bsd@yahoo.com cc: freebsd-arch@freebsd.org Subject: Re: IRQ 2 problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2004 10:35:11 -0000 In message: <1072952198.3233.24.camel@herring.nlsystems.com> Doug Rabson writes: : On Wed, 2003-12-31 at 20:25, M. Warner Losh wrote: : > In message: : > John Baldwin writes: : > : : > : On 31-Dec-2003 Rostislav Krasny wrote: : > : > --- "M. Warner Losh" wrote: : > : >> In message: <20031230.190927.108191769.imp@bsdimp.com> : > : >> "M. Warner Losh" writes: : > : >> : The reason that it iasn't been committed is because it is : > : >> incorrect. : > : >> : : > : >> : : > : >> : > : > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=15473+0+archive/2003/freebsd-arch/20030831.freebsd-ar : > : > ch : > : >> : : > : >> : has the particulars. : > : >> : > : >> Does your machine have an APIC? My laptop doesn't seem to exhibit : > : >> the problem. : > : > : > : > No, it doesn't seem to have an APIC. This is Pentium MMX 200MHz machine : > : > based on Intel's 430TX chipset. : > : > : > : > What is the correct way to fix this IRQ 2 problem? I can help to test it. : > : : > : IRQ 2 in FreeBSD is spelled IRQ 9. If a PNP device wants to use IRQ 2, it : > : can be set to IRQ 2 in hardware, but it must use IRQ 9 when doing the : > : bus_alloc_resource() and bus_setup_intr(). : > : > Actually the problem appears to be that the hardware wants 9 too. '2' : > shouldn't be used at all, nor given out in allocation when we're using : > AT PIC because that's the chaining IRQ. That's the current problem. : > Eg, the isa bus is handing out '2' when it has no buisness doing so. : : The original fix for this which has been lost over the years was to : exclude IRQ2 from the set of available interrupts. When the PnP code : attempted to allocate an irq for the device, it would try for 2, not get : it and settle for 9. : : At some point, IRQ2 was added back into the set but the PIC driver was : fixed to allocate IRQ2 itself as early as possible. This matches the way : the hardware is wired together and has a certain 'rightness' to it. : Unfortunately the PIC driver doesn't seem to allocate IRQ2 for itself : any more which makes it available for broken PnP devices. It looks like IRQ2 isn't registered as an interrupt source, so when we create the resource map, it looks like we skip it and shouldn't be handing it out... Warner From owner-freebsd-arch@FreeBSD.ORG Thu Jan 1 07:12:53 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4503416A4CE for ; Thu, 1 Jan 2004 07:12:53 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F15B43D1F; Thu, 1 Jan 2004 07:12:52 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i01FCoFR056628; Thu, 1 Jan 2004 07:12:51 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <3FF43B93.5060209@freebsd.org> Date: Thu, 01 Jan 2004 23:24:03 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Rabson References: <1072537553.1143.19.camel@herring.nlsystems.com> In-Reply-To: <1072537553.1143.19.camel@herring.nlsystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: sigaltstack with threads X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2004 15:12:53 -0000 Doug Rabson wrote: > I think that if its supported at all in threaded programs, it must be > per-thread state otherwise you can't prevent two different threads > colliding on the same signal stack. I can't quite see how this maps to > KSE/KSEG since I only have the most hazy model of that stuff in my head > right now. > > Anyway, I've worked around things by not setting SA_ONSTACK for the > handlers that I want to run on the thread stack. > > I have worked out a patch to support per-thread sigaltstack() state, in most cases, it is just a literally replacement. http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs David Xu From owner-freebsd-arch@FreeBSD.ORG Thu Jan 1 07:56:52 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A24DD16A4CE; Thu, 1 Jan 2004 07:56:52 -0800 (PST) Received: from herring.nlsystems.com (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0744443D55; Thu, 1 Jan 2004 07:56:51 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from [10.0.0.2] (herring.nlsystems.com [10.0.0.2]) i01FudlM077417; Thu, 1 Jan 2004 15:56:39 GMT (envelope-from dfr@nlsystems.com) From: Doug Rabson To: David Xu In-Reply-To: <3FF43B93.5060209@freebsd.org> References: <1072537553.1143.19.camel@herring.nlsystems.com> <3FF43B93.5060209@freebsd.org> Content-Type: text/plain Message-Id: <1072972599.3233.26.camel@herring.nlsystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 01 Jan 2004 15:56:39 +0000 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on herring.nlsystems.com cc: arch@freebsd.org Subject: Re: sigaltstack with threads X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2004 15:56:52 -0000 On Thu, 2004-01-01 at 15:24, David Xu wrote: > Doug Rabson wrote: > > I think that if its supported at all in threaded programs, it must be > > per-thread state otherwise you can't prevent two different threads > > colliding on the same signal stack. I can't quite see how this maps to > > KSE/KSEG since I only have the most hazy model of that stuff in my head > > right now. > > > > Anyway, I've worked around things by not setting SA_ONSTACK for the > > handlers that I want to run on the thread stack. > > > > > I have worked out a patch to support per-thread sigaltstack() state, > in most cases, it is just a literally replacement. > > http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs Looks fine to me. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 1 08:48:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45DA516A4CE; Thu, 1 Jan 2004 08:48:26 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F7843D54; Thu, 1 Jan 2004 08:48:25 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i01GmOiw020728; Thu, 1 Jan 2004 11:48:24 -0500 (EST) Date: Thu, 1 Jan 2004 11:48:24 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: David Xu In-Reply-To: <3FF43B93.5060209@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: sigaltstack with threads X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2004 16:48:26 -0000 On Thu, 1 Jan 2004, David Xu wrote: > Doug Rabson wrote: > > I think that if its supported at all in threaded programs, it must be > > per-thread state otherwise you can't prevent two different threads > > colliding on the same signal stack. I can't quite see how this maps to > > KSE/KSEG since I only have the most hazy model of that stuff in my head > > right now. > > > > Anyway, I've worked around things by not setting SA_ONSTACK for the > > handlers that I want to run on the thread stack. > > > > > I have worked out a patch to support per-thread sigaltstack() state, > in most cases, it is just a literally replacement. > > http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs Looks good, but I have a question. You removed the proc lock in kern_sig.c:osigstack() and kern_sig.c:kern_sigaltstack(). What prevents a signal from being sent to the current thread while it is mucking with the altsigstack? Is it possible for an interrupt to swap out the current thread and have a signal installed for it sometime later before it can complete sigaltstack()? Or do signals only get installed on the way out of the kernel? -- Dan Eischen From owner-freebsd-arch@FreeBSD.ORG Thu Jan 1 16:15:23 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D7216A4CF for ; Thu, 1 Jan 2004 16:15:23 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C89743D39; Thu, 1 Jan 2004 16:15:22 -0800 (PST) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (davidxu@localhost [127.0.0.1]) i020FKFR003221; Thu, 1 Jan 2004 16:15:21 -0800 (PST) (envelope-from davidxu@freebsd.org) Message-ID: <3FF4BABA.5000601@freebsd.org> Date: Fri, 02 Jan 2004 08:26:34 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031208 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: sigaltstack with threads X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 00:15:23 -0000 Daniel Eischen wrote: > On Thu, 1 Jan 2004, David Xu wrote: > > >>Doug Rabson wrote: >> >>>I think that if its supported at all in threaded programs, it must be >>>per-thread state otherwise you can't prevent two different threads >>>colliding on the same signal stack. I can't quite see how this maps to >>>KSE/KSEG since I only have the most hazy model of that stuff in my head >>>right now. >>> >>>Anyway, I've worked around things by not setting SA_ONSTACK for the >>>handlers that I want to run on the thread stack. >>> >>> >> >>I have worked out a patch to support per-thread sigaltstack() state, >>in most cases, it is just a literally replacement. >> >>http://people.freebsd.org/~davidxu/kse/kern_sigaltstack.diffs > > > Looks good, but I have a question. You removed the proc lock > in kern_sig.c:osigstack() and kern_sig.c:kern_sigaltstack(). > What prevents a signal from being sent to the current thread > while it is mucking with the altsigstack? Is it possible for > an interrupt to swap out the current thread and have a signal > installed for it sometime later before it can complete > sigaltstack()? Or do signals only get installed on the way > out of the kernel? > signal stack only gets installed when thread is on the way out of kernel. Other threads only can post signal to the thread and may wake it up if it is sleeping, but cann't install a signal stack for the thread, the signaled thread checks signals when it is returning to userland, and installs signal stack for itself, sigaltstack is private for thread, and other threads needn't to know the signaled thread has an alternative signal stack at all. David Xu From owner-freebsd-arch@FreeBSD.ORG Fri Jan 2 08:31:41 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9793616A4CE for ; Fri, 2 Jan 2004 08:31:41 -0800 (PST) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id C372643D2D for ; Fri, 2 Jan 2004 08:31:39 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 3184 invoked from network); 2 Jan 2004 16:31:39 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Jan 2004 16:31:39 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i02GVNM0002423; Fri, 2 Jan 2004 11:31:23 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040101.033444.103565788.imp@bsdimp.com> Date: Fri, 02 Jan 2004 11:31:23 -0500 (EST) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: rosti_bsd@yahoo.com cc: freebsd-arch@freebsd.org Subject: Re: IRQ 2 problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 16:31:41 -0000 On 01-Jan-2004 M. Warner Losh wrote: > In message: <1072952198.3233.24.camel@herring.nlsystems.com> > Doug Rabson writes: >: On Wed, 2003-12-31 at 20:25, M. Warner Losh wrote: >: > In message: >: > John Baldwin writes: >: > : >: > : On 31-Dec-2003 Rostislav Krasny wrote: >: > : > --- "M. Warner Losh" wrote: >: > : >> In message: <20031230.190927.108191769.imp@bsdimp.com> >: > : >> "M. Warner Losh" writes: >: > : >> : The reason that it iasn't been committed is because it is >: > : >> incorrect. >: > : >> : >: > : >> : >: > : >> >: > : > http://docs.freebsd.org/cgi/getmsg.cgi?fetch=15473+0+archive/2003/freebsd-arch/20030831.fre >: > : > ebsd-ar >: > : > ch >: > : >> : >: > : >> : has the particulars. >: > : >> >: > : >> Does your machine have an APIC? My laptop doesn't seem to exhibit >: > : >> the problem. >: > : > >: > : > No, it doesn't seem to have an APIC. This is Pentium MMX 200MHz machine >: > : > based on Intel's 430TX chipset. >: > : > >: > : > What is the correct way to fix this IRQ 2 problem? I can help to test it. >: > : >: > : IRQ 2 in FreeBSD is spelled IRQ 9. If a PNP device wants to use IRQ 2, it >: > : can be set to IRQ 2 in hardware, but it must use IRQ 9 when doing the >: > : bus_alloc_resource() and bus_setup_intr(). >: > >: > Actually the problem appears to be that the hardware wants 9 too. '2' >: > shouldn't be used at all, nor given out in allocation when we're using >: > AT PIC because that's the chaining IRQ. That's the current problem. >: > Eg, the isa bus is handing out '2' when it has no buisness doing so. >: >: The original fix for this which has been lost over the years was to >: exclude IRQ2 from the set of available interrupts. When the PnP code >: attempted to allocate an irq for the device, it would try for 2, not get >: it and settle for 9. >: >: At some point, IRQ2 was added back into the set but the PIC driver was >: fixed to allocate IRQ2 itself as early as possible. This matches the way >: the hardware is wired together and has a certain 'rightness' to it. >: Unfortunately the PIC driver doesn't seem to allocate IRQ2 for itself >: any more which makes it available for broken PnP devices. > > It looks like IRQ2 isn't registered as an interrupt source, so when we > create the resource map, it looks like we skip it and shouldn't be > handing it out... Yes, it doesn't exist as a valid IRQ in the irq map anymore. Oh, but you know what, the resource manager is really buggy in this respect. For example, on my system here: Interrupt request lines: 0x0 (root0) 0x1 (atkbd0) 0x2 (root0) 0x3 (sio1) 0x4 (sio0) 0x5-0x8 (root0) 0x9 (acpi0) 0xa-0xb (root0) 0xc (psm0) 0xd (npx0) 0xe (ata0) 0xf (ata1) 0x10 (uhci0) 0x11 (sis0) 0x12 (uhci2) 0x13 (uhci1) 0x14 (fxp0) 0x15-0x17 (root0) Note that the nexus didn't add IRQ 2 as a possible resource, but the resource manager went ahead and added it anyway when the adjacent regions were added. Someone should fix the resource manager code perhaps. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Fri Jan 2 08:37:32 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB2D16A4CE; Fri, 2 Jan 2004 08:37:32 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE25743D31; Fri, 2 Jan 2004 08:37:30 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i02GbUOI011334; Fri, 2 Jan 2004 09:37:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2004 09:37:12 -0700 (MST) Message-Id: <20040102.093712.113734642.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20040101.033444.103565788.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: rosti_bsd@yahoo.com cc: freebsd-arch@FreeBSD.org Subject: Re: IRQ 2 problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 16:37:32 -0000 In message: John Baldwin writes: : > It looks like IRQ2 isn't registered as an interrupt source, so when we : > create the resource map, it looks like we skip it and shouldn't be : > handing it out... : : Yes, it doesn't exist as a valid IRQ in the irq map anymore. Oh, but you : know what, the resource manager is really buggy in this respect. For example, : on my system here: : : Interrupt request lines: : 0x0 (root0) : 0x1 (atkbd0) : 0x2 (root0) : 0x3 (sio1) : 0x4 (sio0) : 0x5-0x8 (root0) : 0x9 (acpi0) : 0xa-0xb (root0) : 0xc (psm0) : 0xd (npx0) : 0xe (ata0) : 0xf (ata1) : 0x10 (uhci0) : 0x11 (sis0) : 0x12 (uhci2) : 0x13 (uhci1) : 0x14 (fxp0) : 0x15-0x17 (root0) : : Note that the nexus didn't add IRQ 2 as a possible resource, but the : resource manager went ahead and added it anyway when the adjacent : regions were added. Someone should fix the resource manager code : perhaps. Interesting. Of course the default behavior for the devinfo stuff is to say that root owns it, so I'm not 100% convinced that it is a bug in the resource manager, necessarily... It fails to report shared resources correctly, but they are none-the-less allocated correctly. I'm curious why the new PIC driver doesn't allocate IRQ 2 itself... Warner From owner-freebsd-arch@FreeBSD.ORG Fri Jan 2 10:27:35 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8047316A4CE for ; Fri, 2 Jan 2004 10:27:35 -0800 (PST) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EDCD43D46 for ; Fri, 2 Jan 2004 10:27:24 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 12748 invoked from network); 2 Jan 2004 18:27:23 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Jan 2004 18:27:23 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i02IRJM0002909; Fri, 2 Jan 2004 13:27:19 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040102.093712.113734642.imp@bsdimp.com> Date: Fri, 02 Jan 2004 13:27:20 -0500 (EST) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: rosti_bsd@yahoo.com cc: freebsd-arch@FreeBSD.org Subject: Re: IRQ 2 problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 18:27:35 -0000 On 02-Jan-2004 M. Warner Losh wrote: > In message: > John Baldwin writes: >: > It looks like IRQ2 isn't registered as an interrupt source, so when we >: > create the resource map, it looks like we skip it and shouldn't be >: > handing it out... >: >: Yes, it doesn't exist as a valid IRQ in the irq map anymore. Oh, but you >: know what, the resource manager is really buggy in this respect. For example, >: on my system here: >: >: Interrupt request lines: >: 0x0 (root0) >: 0x1 (atkbd0) >: 0x2 (root0) >: 0x3 (sio1) >: 0x4 (sio0) >: 0x5-0x8 (root0) >: 0x9 (acpi0) >: 0xa-0xb (root0) >: 0xc (psm0) >: 0xd (npx0) >: 0xe (ata0) >: 0xf (ata1) >: 0x10 (uhci0) >: 0x11 (sis0) >: 0x12 (uhci2) >: 0x13 (uhci1) >: 0x14 (fxp0) >: 0x15-0x17 (root0) >: >: Note that the nexus didn't add IRQ 2 as a possible resource, but the >: resource manager went ahead and added it anyway when the adjacent >: regions were added. Someone should fix the resource manager code >: perhaps. > > Interesting. Of course the default behavior for the devinfo stuff is > to say that root owns it, so I'm not 100% convinced that it is a bug > in the resource manager, necessarily... It fails to report shared > resources correctly, but they are none-the-less allocated correctly. > > I'm curious why the new PIC driver doesn't allocate IRQ 2 itself... It does it by not making it available in the first place. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Fri Jan 2 10:32:01 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AC5F16A4CE; Fri, 2 Jan 2004 10:32:01 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2E7343D5E; Fri, 2 Jan 2004 10:31:56 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i02IVtOI012480; Fri, 2 Jan 2004 11:31:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2004 11:31:53 -0700 (MST) Message-Id: <20040102.113153.90116271.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20040102.093712.113734642.imp@bsdimp.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: rosti_bsd@yahoo.com cc: freebsd-arch@FreeBSD.org Subject: Re: IRQ 2 problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 18:32:01 -0000 In message: John Baldwin writes: : On 02-Jan-2004 M. Warner Losh wrote: : > In message: : > John Baldwin writes: : >: > It looks like IRQ2 isn't registered as an interrupt source, so when we : >: > create the resource map, it looks like we skip it and shouldn't be : >: > handing it out... : >: : >: Yes, it doesn't exist as a valid IRQ in the irq map anymore. Oh, but you : >: know what, the resource manager is really buggy in this respect. For example, : >: on my system here: : >: : >: Interrupt request lines: : >: 0x0 (root0) : >: 0x1 (atkbd0) : >: 0x2 (root0) : >: 0x3 (sio1) : >: 0x4 (sio0) : >: 0x5-0x8 (root0) : >: 0x9 (acpi0) : >: 0xa-0xb (root0) : >: 0xc (psm0) : >: 0xd (npx0) : >: 0xe (ata0) : >: 0xf (ata1) : >: 0x10 (uhci0) : >: 0x11 (sis0) : >: 0x12 (uhci2) : >: 0x13 (uhci1) : >: 0x14 (fxp0) : >: 0x15-0x17 (root0) : >: : >: Note that the nexus didn't add IRQ 2 as a possible resource, but the : >: resource manager went ahead and added it anyway when the adjacent : >: regions were added. Someone should fix the resource manager code : >: perhaps. : > : > Interesting. Of course the default behavior for the devinfo stuff is : > to say that root owns it, so I'm not 100% convinced that it is a bug : > in the resource manager, necessarily... It fails to report shared : > resources correctly, but they are none-the-less allocated correctly. : > : > I'm curious why the new PIC driver doesn't allocate IRQ 2 itself... : : It does it by not making it available in the first place. I'd have expected it to be more like: Interrupt request lines: ... 0x2 (atpic0) ... Warner From owner-freebsd-arch@FreeBSD.ORG Fri Jan 2 11:24:25 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDEF216A4CE for ; Fri, 2 Jan 2004 11:24:25 -0800 (PST) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 178A643D1D for ; Fri, 2 Jan 2004 11:24:08 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 24319 invoked from network); 2 Jan 2004 19:24:07 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Jan 2004 19:24:07 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.10/8.12.10) with ESMTP id i02JO3M0003210; Fri, 2 Jan 2004 14:24:04 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040102.113153.90116271.imp@bsdimp.com> Date: Fri, 02 Jan 2004 14:24:05 -0500 (EST) From: John Baldwin To: "M. Warner Losh" X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: rosti_bsd@yahoo.com cc: freebsd-arch@FreeBSD.org Subject: Re: IRQ 2 problem X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2004 19:24:26 -0000 On 02-Jan-2004 M. Warner Losh wrote: > In message: > John Baldwin writes: >: On 02-Jan-2004 M. Warner Losh wrote: >: > In message: >: > John Baldwin writes: >: >: > It looks like IRQ2 isn't registered as an interrupt source, so when we >: >: > create the resource map, it looks like we skip it and shouldn't be >: >: > handing it out... >: >: >: >: Yes, it doesn't exist as a valid IRQ in the irq map anymore. Oh, but you >: >: know what, the resource manager is really buggy in this respect. For example, >: >: on my system here: >: >: >: >: Interrupt request lines: >: >: 0x0 (root0) >: >: 0x1 (atkbd0) >: >: 0x2 (root0) >: >: 0x3 (sio1) >: >: 0x4 (sio0) >: >: 0x5-0x8 (root0) >: >: 0x9 (acpi0) >: >: 0xa-0xb (root0) >: >: 0xc (psm0) >: >: 0xd (npx0) >: >: 0xe (ata0) >: >: 0xf (ata1) >: >: 0x10 (uhci0) >: >: 0x11 (sis0) >: >: 0x12 (uhci2) >: >: 0x13 (uhci1) >: >: 0x14 (fxp0) >: >: 0x15-0x17 (root0) >: >: >: >: Note that the nexus didn't add IRQ 2 as a possible resource, but the >: >: resource manager went ahead and added it anyway when the adjacent >: >: regions were added. Someone should fix the resource manager code >: >: perhaps. >: > >: > Interesting. Of course the default behavior for the devinfo stuff is >: > to say that root owns it, so I'm not 100% convinced that it is a bug >: > in the resource manager, necessarily... It fails to report shared >: > resources correctly, but they are none-the-less allocated correctly. >: > >: > I'm curious why the new PIC driver doesn't allocate IRQ 2 itself... >: >: It does it by not making it available in the first place. > > I'd have expected it to be more like: > > Interrupt request lines: > ... > 0x2 (atpic0) > ... No, I mean it shouldn't exist. It should be: 0x0 (root0) (this is a bug cause clk isn't new-bussed) 0x1 (atkbd0) 0x3 (sio1) ... -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 14:37:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48F3816A4CE for ; Sat, 3 Jan 2004 14:37:00 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56ED843D46 for ; Sat, 3 Jan 2004 14:36:57 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i03MauET013735 for ; Sat, 3 Jan 2004 15:36:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Jan 2004 15:36:44 -0700 (MST) Message-Id: <20040103.153644.107852018.imp@bsdimp.com> To: arch@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Simple patch: Make DFLTPHYS an option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2004 22:37:00 -0000 My brother was talking to me about the problems he was having with scanners. Turns out that he needed to incrase DFLTYPHYS to 128k to make it work. I'd like to make this a simple option, but wanted to ask people about it first, for both DFLTPHYS and MAXPHYS. This would be an experts only option, since you can do bad things with some drivers (eg, aha can't do more than 64k of physio at a time, and bad things may happen if you try > 128k). The folks on IRC cautioned that this is not for the feign of heart, since there's 'issues' with physio, MAXPHYS, etc. Comments? Warner P.S. Here's a trivial patch to implement this: ==== //depot/user/imp/newcard/conf/options#70 - /dell/imp/p4/newcard/src/sys/conf/options ==== @@ -470,10 +470,12 @@ DEBUG opt_global.h DEBUG_LOCKS opt_global.h DEBUG_VFS_LOCKS opt_global.h +DFLTPHYS opt_global.h DIAGNOSTIC opt_global.h INVARIANT_SUPPORT opt_global.h INVARIANTS opt_global.h LOOKUP_SHARED opt_global.h +MAXPHYS opt_global.h MCLSHIFT opt_global.h MSIZE opt_global.h REGRESSION opt_global.h From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 19:06:49 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC97D16A4CE for ; Sat, 3 Jan 2004 19:06:49 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0AF4543D64 for ; Sat, 3 Jan 2004 19:06:43 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 40035 invoked from network); 4 Jan 2004 03:06:41 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 4 Jan 2004 03:06:41 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 3 Jan 2004 21:06:39 -0600 (CST) From: Mike Silbersack To: arch@freebsd.org Message-ID: <20040103205152.G5165@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-581488147-1073185599=:5165" Subject: RFC: Sendfile patch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 03:06:49 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-581488147-1073185599=:5165 Content-Type: TEXT/PLAIN; charset=US-ASCII The attached patch (also available from the following url): http://www.silby.com/patches/raw/sendfile-wip4.patch modifies sendfile to ensure that the header is sent in the same packet as the data from the file. This greatly helps performance when dealing with http servers, as it allows small files to fit in one packet, instead of two. In order to keep the implementation relatively simple, I have created two helper functions, iov_to_uio, and m_uiotombuf. You'll note that iov_to_uio contains the body of readv/writev almost exactly, and m_uiotombuf does much the same thing as sosend. (In the future, I may attempt to make readv/writev use iov_to_uio, and have sosend use m_uiotombuf, but that's a project for another day.) I'm going to be gone for two weeks, so that should allow plenty of time for testing / review of the patch. The location(s) of iov_to_uio and m_uiotombuf in both source and header files sounds like an easy thing to bikeshed about, so please don't bring that up. Such matters can be discussed when I get back, because I commit it. What I am interested in are reviews of the actual code, specifically regarding any possible security holes which I may be introducing. Also, I would appreciate it if someone could verify that I have the old sendfile compatibility part working correctly, as it is quite messy. If you're not in the mood to review the patch, please feel free to test it. I have only tested with apache2 and thttpd (with alfred's sf patches from the port enabled), there are undoubtedly many other programs which make use of sendfile and should be tested. If you have any sort of web benchmark which helps to show the performance increase given by this patch, please run it; it's always great to include statistics in a commit message. Naturally, the patch is against -current. If you have any questions, please ask quickly, or prepare to wait a long time for an answer. :) Mike "Silby" Silbersack --0-581488147-1073185599=:5165 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="sendfile-wip4.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20040103210639.K5165@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="sendfile-wip4.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL2tlcm4vdWlwY19tYnVmLmMg L3Vzci9zcmMvc3lzL2tlcm4vdWlwY19tYnVmLmMNCi0tLSAvdXNyL3NyYy9z eXMub2xkL2tlcm4vdWlwY19tYnVmLmMJU2F0IEphbiAgMyAxOTo1MToyOSAy MDA0DQorKysgL3Vzci9zcmMvc3lzL2tlcm4vdWlwY19tYnVmLmMJU2F0IEph biAgMyAyMDoxNDowMyAyMDA0DQpAQCAtNDMsNiArNDMsNyBAQA0KICNpbmNs dWRlIDxzeXMvcGFyYW0uaD4NCiAjaW5jbHVkZSA8c3lzL3N5c3RtLmg+DQog I2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4NCisjaW5jbHVkZSA8c3lzL2xpbWl0 cy5oPg0KICNpbmNsdWRlIDxzeXMvbG9jay5oPg0KICNpbmNsdWRlIDxzeXMv bWFjLmg+DQogI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4NCkBAIC01MCw2ICs1 MSw3IEBADQogI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4NCiAjaW5jbHVkZSA8 c3lzL2RvbWFpbi5oPg0KICNpbmNsdWRlIDxzeXMvcHJvdG9zdy5oPg0KKyNp bmNsdWRlIDxzeXMvdWlvLmg+DQogDQogaW50CW1heF9saW5raGRyOw0KIGlu dAltYXhfcHJvdG9oZHI7DQpAQCAtMTAyOCwzICsxMDMwLDk5IEBADQogfQ0K IA0KICNlbmRpZg0KKw0KK3N0cnVjdCBtYnVmICoNCittX3Vpb3RvbWJ1Zihz dHJ1Y3QgdWlvICp1aW8sIGludCBob3csIGludCBsZW4pDQorew0KKwlzdHJ1 Y3QgbWJ1ZgkqbV9uZXcgPSBOVUxMLCAqbV9maW5hbCA9IE5VTEw7DQorCWlu dAkJcHJvZ3Jlc3MgPSAwLCBlcnJvciA9IDAsIGxlbmd0aCwgdG90YWw7DQor DQorCWlmIChsZW4gPiAwKQ0KKwkJdG90YWwgPSBtaW4odWlvLT51aW9fcmVz aWQsIGxlbik7DQorCWVsc2UNCisJCXRvdGFsID0gdWlvLT51aW9fcmVzaWQ7 DQorDQorCWlmICh0b3RhbCA+IE1ITEVOKQ0KKwkJbV9maW5hbCA9IG1fZ2V0 Y2woaG93LCBNVF9EQVRBLCBNX1BLVEhEUik7DQorCWVsc2UNCisJCW1fZmlu YWwgPSBtX2dldGhkcihob3csIE1UX0RBVEEpOw0KKw0KKwlpZiAobV9maW5h bCA9PSBOVUxMKQ0KKwkJZ290byBub3NwYWNlOw0KKw0KKwltX25ldyA9IG1f ZmluYWw7DQorDQorCXdoaWxlIChwcm9ncmVzcyA8IHRvdGFsKSB7DQorCQls ZW5ndGggPSB0b3RhbCAtIHByb2dyZXNzOw0KKwkJaWYgKGxlbmd0aCA+IE1D TEJZVEVTKQ0KKwkJCWxlbmd0aCA9IE1DTEJZVEVTOw0KKw0KKwkJaWYgKG1f bmV3ID09IE5VTEwpIHsNCisJCQlpZiAobGVuZ3RoID4gTUxFTikNCisJCQkJ bV9uZXcgPSBtX2dldGNsKGhvdywgTVRfREFUQSwgMCk7DQorCQkJZWxzZQ0K KwkJCQltX25ldyA9IG1fZ2V0KGhvdywgTVRfREFUQSk7DQorCQkJaWYgKG1f bmV3ID09IE5VTEwpDQorCQkJCWdvdG8gbm9zcGFjZTsNCisJCX0NCisNCisJ CWVycm9yID0gdWlvbW92ZShtdG9kKG1fbmV3LCB2b2lkICopLCBsZW5ndGgs IHVpbyk7DQorCQlpZiAoZXJyb3IpDQorCQkJZ290byBub3NwYWNlOw0KKwkJ cHJvZ3Jlc3MgKz0gbGVuZ3RoOw0KKwkJbV9uZXctPm1fbGVuID0gbGVuZ3Ro Ow0KKwkJaWYgKG1fbmV3ICE9IG1fZmluYWwpDQorCQkJbV9jYXQobV9maW5h bCwgbV9uZXcpOw0KKwkJbV9uZXcgPSBOVUxMOw0KKwl9DQorCW1fZml4aGRy KG1fZmluYWwpOw0KKwlyZXR1cm4gKG1fZmluYWwpOw0KK25vc3BhY2U6DQor CWlmIChtX25ldykNCisJCW1fZnJlZShtX25ldyk7DQorCWlmIChtX2ZpbmFs KQ0KKwkJbV9mcmVlbShtX2ZpbmFsKTsNCisJcmV0dXJuIChOVUxMKTsNCit9 DQorDQoraW50DQoraW92X3RvX3VpbyhzdHJ1Y3QgaW92ZWMgKmlvdnAsIHVf aW50IGlvdmNudCwgc3RydWN0IHVpbyAqYXVpbykNCit7DQorCWludCBlcnJv ciA9IDAsIGk7DQorCXVfaW50IGlvdmxlbjsNCisJc3RydWN0IGlvdmVjICpp b3YgPSBOVUxMOw0KKw0KKwlpZiAoaW92Y250IDwgMCkNCisJCXBhbmljKCJp b3ZjbnQgPCAwIVxuIik7DQorDQorICAgICAgICAvKiBub3RlOiBjYW4ndCB1 c2UgaW92bGVuIHVudGlsIGlvdmNudCBpcyB2YWxpZGF0ZWQgKi8NCisgICAg ICAgIGlvdmxlbiA9IGlvdmNudCAqIHNpemVvZiAoc3RydWN0IGlvdmVjKTsN CisgICAgICAgIGlmIChpb3ZjbnQgPiBVSU9fTUFYSU9WKSB7DQorICAgICAg ICAgICAgICAgZXJyb3IgPSBFSU5WQUw7DQorICAgICAgICAgICAgICAgZ290 byBkb25lOw0KKyAgICAgICAgfQ0KKyAgICAgICAgTUFMTE9DKGlvdiwgc3Ry dWN0IGlvdmVjICosIGlvdmxlbiwgTV9JT1YsIE1fV0FJVE9LKTsNCisgICAg ICAgIGF1aW8tPnVpb19pb3YgPSBpb3Y7DQorICAgICAgICBhdWlvLT51aW9f aW92Y250ID0gaW92Y250Ow0KKyAgICAgICAgYXVpby0+dWlvX3NlZ2ZsZyA9 IFVJT19VU0VSU1BBQ0U7DQorICAgICAgICBhdWlvLT51aW9fb2Zmc2V0ID0g LTE7DQorICAgICAgICBpZiAoKGVycm9yID0gY29weWluKGlvdnAsIGlvdiwg aW92bGVuKSkpDQorICAgICAgICAgICAgICAgIGdvdG8gZG9uZTsNCisgICAg ICAgIGF1aW8tPnVpb19yZXNpZCA9IDA7DQorICAgICAgICBmb3IgKGkgPSAw OyBpIDwgaW92Y250OyBpKyspIHsNCisgICAgICAgICAgICAgICAgaWYgKGlv di0+aW92X2xlbiA+IElOVF9NQVggLSBhdWlvLT51aW9fcmVzaWQpIHsNCisg ICAgICAgICAgICAgICAgICAgICAgICBlcnJvciA9IEVJTlZBTDsNCisgICAg ICAgICAgICAgICAgICAgICAgICBnb3RvIGRvbmU7DQorICAgICAgICAgICAg ICAgIH0NCisgICAgICAgICAgICAgICAgYXVpby0+dWlvX3Jlc2lkICs9IGlv di0+aW92X2xlbjsNCisgICAgICAgICAgICAgICAgaW92Kys7DQorICAgICAg ICB9DQorDQorZG9uZToNCisJaWYgKGVycm9yICYmIGF1aW8tPnVpb19pb3Yp IHsNCisJCUZSRUUoYXVpby0+dWlvX2lvdiwgTV9JT1YpOw0KKwkJYXVpby0+ dWlvX2lvdiA9IE5VTEw7DQorCX0NCisJcmV0dXJuIChlcnJvcik7DQorDQor fQ0KZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL2tlcm4vdWlwY19zeXNj YWxscy5jIC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc3lzY2FsbHMuYw0KLS0t IC91c3Ivc3JjL3N5cy5vbGQva2Vybi91aXBjX3N5c2NhbGxzLmMJU2F0IEph biAgMyAxOTo1MToyOSAyMDA0DQorKysgL3Vzci9zcmMvc3lzL2tlcm4vdWlw Y19zeXNjYWxscy5jCVNhdCBKYW4gIDMgMjA6MTU6MDggMjAwNA0KQEAgLTE2 NjcsMTMgKzE2NjcsMTUgQEANCiAJc3RydWN0IHZub2RlICp2cDsNCiAJc3Ry dWN0IHZtX29iamVjdCAqb2JqOw0KIAlzdHJ1Y3Qgc29ja2V0ICpzbyA9IE5V TEw7DQotCXN0cnVjdCBtYnVmICptOw0KKwlzdHJ1Y3QgbWJ1ZiAqbSwgKm1f aGVhZGVyID0gTlVMTDsNCiAJc3RydWN0IHNmX2J1ZiAqc2Y7DQogCXN0cnVj dCB2bV9wYWdlICpwZzsNCiAJc3RydWN0IHdyaXRldl9hcmdzIG51YXA7DQog CXN0cnVjdCBzZl9oZHRyIGhkdHI7DQorCXN0cnVjdCB1aW8gaGRyX3VpbzsN CiAJb2ZmX3Qgb2ZmLCB4ZnNpemUsIGhkdHJfc2l6ZSwgc2J5dGVzID0gMDsN Ci0JaW50IGVycm9yLCBzOw0KKwlpbnQgZXJyb3IsIHMsIGhlYWRlcnNpemUg PSAwLCBoZWFkZXJzZW50ID0gMDsNCisJc3RydWN0IGlvdmVjICpoZHJfaW92 ID0gTlVMTDsNCiANCiAJbXR4X2xvY2soJkdpYW50KTsNCiANCkBAIC0xNzIx LDE5ICsxNzIzLDI1IEBADQogCQlpZiAoZXJyb3IpDQogCQkJZ290byBkb25l Ow0KIAkJLyoNCi0JCSAqIFNlbmQgYW55IGhlYWRlcnMuIFdpbXAgb3V0IGFu ZCB1c2Ugd3JpdGV2KDIpLg0KKwkJICogU2VuZCBhbnkgaGVhZGVycy4NCiAJ CSAqLw0KIAkJaWYgKGhkdHIuaGVhZGVycyAhPSBOVUxMKSB7DQotCQkJbnVh cC5mZCA9IHVhcC0+czsNCi0JCQludWFwLmlvdnAgPSBoZHRyLmhlYWRlcnM7 DQotCQkJbnVhcC5pb3ZjbnQgPSBoZHRyLmhkcl9jbnQ7DQotCQkJZXJyb3Ig PSB3cml0ZXYodGQsICZudWFwKTsNCisJCQloZHJfdWlvLnVpb190ZCA9IHRk Ow0KKwkJCWhkcl91aW8udWlvX3J3ID0gVUlPX1dSSVRFOw0KKwkJCWVycm9y ID0gaW92X3RvX3VpbyhoZHRyLmhlYWRlcnMsIGhkdHIuaGRyX2NudCwNCisJ CQkJJmhkcl91aW8pOw0KIAkJCWlmIChlcnJvcikNCiAJCQkJZ290byBkb25l Ow0KLQkJCWlmIChjb21wYXQpDQotCQkJCXNieXRlcyArPSB0ZC0+dGRfcmV0 dmFsWzBdOw0KLQkJCWVsc2UNCi0JCQkJaGR0cl9zaXplICs9IHRkLT50ZF9y ZXR2YWxbMF07DQorCQkJLyogQ2FjaGUgaGRyX2lvdiwgbV91aW90b21idWYg bWF5IGNoYW5nZSBpdC4gKi8NCisJCQloZHJfaW92ID0gaGRyX3Vpby51aW9f aW92Ow0KKwkJCWlmIChoZHJfdWlvLnVpb19yZXNpZCA+IDApIHsNCisJCQkJ bV9oZWFkZXIgPSBtX3Vpb3RvbWJ1ZigmaGRyX3VpbywgTV9ET05UV0FJVCwg MCk7DQorCQkJCWlmIChtX2hlYWRlciA9PSBOVUxMKQ0KKwkJCQkJZ290byBk b25lOw0KKwkJCQloZWFkZXJzaXplID0gbV9oZWFkZXItPm1fcGt0aGRyLmxl bjsNCisJCQkJaWYgKGNvbXBhdCkNCisJCQkJCXNieXRlcyArPSBoZWFkZXJz aXplOw0KKwkJCX0NCiAJCX0NCiAJfQ0KIA0KQEAgLTE4OTAsNyArMTg5OCwx MCBAQA0KIAkJLyoNCiAJCSAqIEdldCBhbiBtYnVmIGhlYWRlciBhbmQgc2V0 IGl0IHVwIGFzIGhhdmluZyBleHRlcm5hbCBzdG9yYWdlLg0KIAkJICovDQot CQlNR0VUSERSKG0sIE1fVFJZV0FJVCwgTVRfREFUQSk7DQorCQlpZiAobV9o ZWFkZXIpDQorCQkJTUdFVChtLCBNX1RSWVdBSVQsIE1UX0RBVEEpOw0KKwkJ ZWxzZQ0KKwkJCU1HRVRIRFIobSwgTV9UUllXQUlULCBNVF9EQVRBKTsNCiAJ CWlmIChtID09IE5VTEwpIHsNCiAJCQllcnJvciA9IEVOT0JVRlM7DQogCQkJ c2ZfYnVmX2ZyZWUoKHZvaWQgKilzZl9idWZfa3ZhKHNmKSwgc2YpOw0KQEAg LTE5MDQsNiArMTkxNSwxNCBAQA0KIAkJICAgIEVYVF9TRkJVRik7DQogCQlt LT5tX2RhdGEgPSAoY2hhciAqKXNmX2J1Zl9rdmEoc2YpICsgcGdvZmY7DQog CQltLT5tX3BrdGhkci5sZW4gPSBtLT5tX2xlbiA9IHhmc2l6ZTsNCisNCisJ CWlmIChtX2hlYWRlcikgew0KKwkJCW1fY2F0KG1faGVhZGVyLCBtKTsNCisJ CQltID0gbV9oZWFkZXI7DQorCQkJbV9oZWFkZXIgPSBOVUxMOw0KKwkJCW1f Zml4aGRyKG0pOw0KKwkJfQ0KKw0KIAkJLyoNCiAJCSAqIEFkZCB0aGUgYnVm ZmVyIHRvIHRoZSBzb2NrZXQgYnVmZmVyIGNoYWluLg0KIAkJICovDQpAQCAt MTk2NSw2ICsxOTg0LDcgQEANCiAJCQlzYnVubG9jaygmc28tPnNvX3NuZCk7 DQogCQkJZ290byBkb25lOw0KIAkJfQ0KKwkJaGVhZGVyc2VudCA9IDE7DQog CX0NCiAJc2J1bmxvY2soJnNvLT5zb19zbmQpOw0KIA0KQEAgLTE5ODUsNiAr MjAwNSwxMyBAQA0KIAl9DQogDQogZG9uZToNCisJaWYgKGhlYWRlcnNlbnQp IHsNCisJCWlmICghY29tcGF0KQ0KKwkJCWhkdHJfc2l6ZSArPSBoZWFkZXJz aXplOw0KKwl9IGVsc2Ugew0KKwkJaWYgKGNvbXBhdCkNCisJCQlzYnl0ZXMg LT0gaGVhZGVyc2l6ZTsNCisJfQ0KIAkvKg0KIAkgKiBJZiB0aGVyZSB3YXMg bm8gZXJyb3Igd2UgaGF2ZSB0byBjbGVhciB0ZC0+dGRfcmV0dmFsWzBdDQog CSAqIGJlY2F1c2UgaXQgbWF5IGhhdmUgYmVlbiBzZXQgYnkgd3JpdGV2Lg0K QEAgLTIwMDEsNiArMjAyOCwxMCBAQA0KIAkJdnJlbGUodnApOw0KIAlpZiAo c28pDQogCQlmcHV0c29jayhzbyk7DQorCWlmIChoZHJfaW92KQ0KKwkJRlJF RShoZHJfaW92LCBNX0lPVik7DQorCWlmIChtX2hlYWRlcikNCisJCW1fZnJl ZW0obV9oZWFkZXIpOw0KIA0KIAltdHhfdW5sb2NrKCZHaWFudCk7DQogDQpP bmx5IGluIC91c3Ivc3JjL3N5cy9rZXJuOiB1aXBjX3N5c2NhbGxzLmMucmVq Lm9yaWcNCmRpZmYgLXUgLXIgL3Vzci9zcmMvc3lzLm9sZC9zeXMvdWlvLmgg L3Vzci9zcmMvc3lzL3N5cy91aW8uaA0KLS0tIC91c3Ivc3JjL3N5cy5vbGQv c3lzL3Vpby5oCVNhdCBKYW4gIDMgMTk6NTE6MzAgMjAwNA0KKysrIC91c3Iv c3JjL3N5cy9zeXMvdWlvLmgJU2F0IEphbiAgMyAyMDoxNjo1MiAyMDA0DQpA QCAtOTQsNiArOTQsOSBAQA0KIGludAl1aW9tb3ZlX2Zyb21idWYodm9pZCAq YnVmLCBpbnQgYnVmbGVuLCBzdHJ1Y3QgdWlvICp1aW8pOw0KIGludAl1aW9t b3ZlY28odm9pZCAqY3AsIGludCBuLCBzdHJ1Y3QgdWlvICp1aW8sIHN0cnVj dCB2bV9vYmplY3QgKm9iaiwNCiAJICAgIGludCBkaXNwb3NhYmxlKTsNCitz dHJ1Y3QgbWJ1ZiAqDQorCW1fdWlvdG9tYnVmKHN0cnVjdCB1aW8gKnVpbywg aW50IGhvdywgaW50IGxlbik7DQoraW50CWlvdl90b191aW8oc3RydWN0IGlv dmVjICppb3ZwLCB1X2ludCBpb3ZjbnQsIHN0cnVjdCB1aW8gKmF1aW8pOw0K IA0KICNlbHNlIC8qICFfS0VSTkVMICovDQogDQo= --0-581488147-1073185599=:5165-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 20:30:26 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 468A316A4CE for ; Sat, 3 Jan 2004 20:30:26 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id DECE543D49 for ; Sat, 3 Jan 2004 20:30:24 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 97906 invoked by uid 1002); 4 Jan 2004 04:30:22 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 4 Jan 2004 04:30:22 -0000 Message-ID: <3FF7967A.1090401@freebsd.org> Date: Sat, 03 Jan 2004 21:28:42 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20040103.153644.107852018.imp@bsdimp.com> In-Reply-To: <20040103.153644.107852018.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Simple patch: Make DFLTPHYS an option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 04:30:26 -0000 M. Warner Losh wrote: > My brother was talking to me about the problems he was having with > scanners. Turns out that he needed to incrase DFLTYPHYS to 128k to > make it work. I'd like to make this a simple option, but wanted to > ask people about it first, for both DFLTPHYS and MAXPHYS. This would > be an experts only option, since you can do bad things with some > drivers (eg, aha can't do more than 64k of physio at a time, and bad > things may happen if you try > 128k). > > The folks on IRC cautioned that this is not for the feign of heart, > since there's 'issues' with physio, MAXPHYS, etc. > > Comments? > > Warner > > P.S. Here's a trivial patch to implement this: > > ==== //depot/user/imp/newcard/conf/options#70 - /dell/imp/p4/newcard/src/sys/conf/options ==== > @@ -470,10 +470,12 @@ > DEBUG opt_global.h > DEBUG_LOCKS opt_global.h > DEBUG_VFS_LOCKS opt_global.h > +DFLTPHYS opt_global.h > DIAGNOSTIC opt_global.h > INVARIANT_SUPPORT opt_global.h > INVARIANTS opt_global.h > LOOKUP_SHARED opt_global.h > +MAXPHYS opt_global.h > MCLSHIFT opt_global.h > MSIZE opt_global.h > REGRESSION opt_global.h I'm really not comfortable with a patch like this. Changing the default i/o size is better served as a per-driver tunable/sysctl, like it is in aac(4). The key, though, is to ensure that the block system is actually honoring the per-device disk.d_maxsize variable. I'm not sure if it is right now. Also, increasing MAXPHYS will lead to your KVA being chewed up quite quickly, which in turn will lead to unpleasant panics. A lot of work needs to go in to fixing this; increasing the value here has little value even to people who shun seatbelts. Scott From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 22:52:14 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21DB816A4CE; Sat, 3 Jan 2004 22:52:14 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FF1243D2D; Sat, 3 Jan 2004 22:52:05 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id RAA02845; Sun, 4 Jan 2004 17:52:02 +1100 Date: Sun, 4 Jan 2004 17:52:01 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Scott Long In-Reply-To: <3FF7967A.1090401@freebsd.org> Message-ID: <20040104172940.L22231@gamplex.bde.org> References: <20040103.153644.107852018.imp@bsdimp.com> <3FF7967A.1090401@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@FreeBSD.org Subject: Re: Simple patch: Make DFLTPHYS an option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 06:52:14 -0000 On Sat, 3 Jan 2004, Scott Long wrote: > M. Warner Losh wrote: > > My brother was talking to me about the problems he was having with > > scanners. Turns out that he needed to incrase DFLTYPHYS to 128k to > > make it work. I'd like to make this a simple option, but wanted to > > ask people about it first, for both DFLTPHYS and MAXPHYS. This would > >... > I'm really not comfortable with a patch like this. Changing the default > i/o size is better served as a per-driver tunable/sysctl, like it is in > aac(4). Right, except it's better served by drivers just supporting the maximum i/o size that the hardware can support, without any tunable or sysctl to break and complicate this support. > The key, though, is to ensure that the block system is actually > honoring the per-device disk.d_maxsize variable. I'm not sure if it is > right now. It at least used to work (up to MAXPHYS). The ad driver used a max i/o size of 128K until recently. This has rotted back to 64K for some reason (64K is encoded as DFLTPHYS in the non-dma case and as 64 * 1024 in the dma case). > Also, increasing MAXPHYS will lead to your KVA being chewed up quite > quickly, which in turn will lead to unpleasant panics. A lot of work > needs to go in to fixing this; increasing the value here has little > value even to people who shun seatbelts. Not all that quicky. MAXPHYS affects mainly pbufs, and there are a limited number of them (256 max?), and their kva is statically allocated. 256 times the current MAXPHYS gives 16M. This could easily be increased by a factor of up to about 8 without necesarily breaking things (e.g., by stealing 112MB from buffer kva using VM_BCACHE_SIZE if the default normal-buffer kva size is large (if it is small then there should be space to spare, else there would be no space to spare on systems with more RAM so that the buffer kva size is larger). Bruce From owner-freebsd-arch@FreeBSD.ORG Sat Jan 3 23:17:05 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4A4216A4CE for ; Sat, 3 Jan 2004 23:17:05 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 0BC9643D58 for ; Sat, 3 Jan 2004 23:17:04 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 2383 invoked by uid 1002); 4 Jan 2004 07:17:01 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 4 Jan 2004 07:17:01 -0000 Message-ID: <3FF7BD89.4080406@freebsd.org> Date: Sun, 04 Jan 2004 00:15:21 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Evans References: <20040103.153644.107852018.imp@bsdimp.com> <3FF7967A.1090401@freebsd.org> <20040104172940.L22231@gamplex.bde.org> In-Reply-To: <20040104172940.L22231@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: Simple patch: Make DFLTPHYS an option X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 07:17:05 -0000 Bruce Evans wrote: > On Sat, 3 Jan 2004, Scott Long wrote: > > >>M. Warner Losh wrote: >> >>>My brother was talking to me about the problems he was having with >>>scanners. Turns out that he needed to incrase DFLTYPHYS to 128k to >>>make it work. I'd like to make this a simple option, but wanted to >>>ask people about it first, for both DFLTPHYS and MAXPHYS. This would >>>... >> >>I'm really not comfortable with a patch like this. Changing the default >>i/o size is better served as a per-driver tunable/sysctl, like it is in >>aac(4). > > > Right, except it's better served by drivers just supporting the maximum > i/o size that the hardware can support, without any tunable or sysctl to > break and complicate this support. > aac(4) is an example of hardware where the limits are somewhat flexible if you know what you are doing. The driver cannot make the more aggressive choice on its own. > >>The key, though, is to ensure that the block system is actually >>honoring the per-device disk.d_maxsize variable. I'm not sure if it is >>right now. > > > It at least used to work (up to MAXPHYS). The ad driver used a max > i/o size of 128K until recently. This has rotted back to 64K for some > reason (64K is encoded as DFLTPHYS in the non-dma case and as 64 * 1024 > in the dma case). > I've seen evidence lately that this might be broken, but I need to track it down further. > >>Also, increasing MAXPHYS will lead to your KVA being chewed up quite >>quickly, which in turn will lead to unpleasant panics. A lot of work >>needs to go in to fixing this; increasing the value here has little >>value even to people who shun seatbelts. > > > Not all that quicky. MAXPHYS affects mainly pbufs, and there are a > limited number of them (256 max?), and their kva is statically allocated. > 256 times the current MAXPHYS gives 16M. This could easily be increased > by a factor of up to about 8 without necesarily breaking things (e.g., > by stealing 112MB from buffer kva using VM_BCACHE_SIZE if the default > normal-buffer kva size is large (if it is small then there should be > space to spare, else there would be no space to spare on systems with > more RAM so that the buffer kva size is larger). > VFS, softupdates, UFS_DIRHASH, etc, all contribute to KVA being eaten faster than it used to be. Even with smarter tuning of common culprits like maxvnodes, KVA is still under a lot of pressure. Scott