From owner-freebsd-acpi@FreeBSD.ORG Fri Apr 15 17:36:30 2005 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6D8616A4CE; Fri, 15 Apr 2005 17:36:30 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34A4443D5A; Fri, 15 Apr 2005 17:36:30 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j3FHaRwe040220; Fri, 15 Apr 2005 12:36:27 -0500 (CDT) (envelope-from dan) Date: Fri, 15 Apr 2005 12:36:27 -0500 From: Dan Nelson To: Marcel Moolenaar Message-ID: <20050415173627.GQ4842@dan.emsphone.com> References: <20050414103154.GA11341@laptop.santcroos.net> <20050414135004.GB75334@unixpages.org> <20050414172147.GA772@laptop.santcroos.net> <20050415162821.GA691@laptop.santcroos.net> <5e7c3d2084ff2460d6e48786defc8f33@xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <5e7c3d2084ff2460d6e48786defc8f33@xcllnt.net> X-OS: FreeBSD 5.4-PRERELEASE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Please test: ACPI-CA import 20050408 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 17:36:30 -0000 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Apr 15), Marcel Moolenaar said: > On Apr 15, 2005, at 9:28 AM, Mark Santcroos wrote: > >On Fri, Apr 15, 2005 at 09:20:52AM -0700, Marcel Moolenaar wrote: > >>BTW: Is ACPICA getting slower? > > > > Might be. I don't have numbers on that. I guess we're still > > focusing on functionality and not so much on speed. Do you have a > > concrete area where you think we are loosing performance? > > No, not yet. It's just that there are 2 "dead" spots in the booting > process of the plutos we have in the cluster and these "dead" spots > appeared to be longer. I think there's a lot of AML interpretation > going on during that time, but I might be wrong. What I have personally seen is a long delay in bus_alloc_resource() on some older Dell machines (desktop and laptop, both under 500Mhz). If I apply the attached patch, I see between 15 and 20 rows of identical output, and each call to b_a_r takes a noticeable fraction of a second (i.e. the cursor spends most of its time after an IRQ, not after a 'y' or 'n'.) The delays probably add 45 seconds total to the boot time. Newer systems will just generate 4 or 5 lines total for the entire boot process. -- Dan Nelson dnelson@allantgroup.com --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="irq.diff" Index: acpi_pci_link.c =================================================================== RCS file: /home/ncvs/src/sys/dev/acpica/acpi_pci_link.c,v retrieving revision 1.24.2.6 diff -u -p -r1.24.2.6 acpi_pci_link.c --- acpi_pci_link.c 7 Nov 2004 20:24:05 -0000 1.24.2.6 +++ acpi_pci_link.c 9 Nov 2004 03:43:52 -0000 @@ -804,17 +804,22 @@ acpi_pci_link_update_irq_penalty(device_ /* XXX try to get this IRQ in non-sharable mode. */ rid = 0; + printf("%d", irq); res = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, irq, irq, 1, 0); if (res != NULL) { + printf("y"); bus_release_resource(dev, SYS_RES_IRQ, rid, res); + printf(" "); } else { /* this is in use, give 10. */ irq_penalty[irq] += 10; + printf("n "); } } + printf("\n"); /* initialize `sorted' possible IRQs. */ bcopy(link->interrupts, link->sorted_irq, sizeof(link->sorted_irq)); --ReaqsoxgOBHFXBhH--