From owner-freebsd-stable@FreeBSD.ORG Thu Mar 24 05:59:20 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B63A106566B for ; Thu, 24 Mar 2011 05:59:20 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 26DAD8FC08 for ; Thu, 24 Mar 2011 05:59:19 +0000 (UTC) Received: by iyj12 with SMTP id 12so11275734iyj.13 for ; Wed, 23 Mar 2011 22:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:in-reply-to :message-id:references:user-agent:x-openpgp-key-id :x-openpgp-key-fingerprint:mime-version:content-type; bh=whrCB5M7r1OX5yUTXmc9DWcNRx1X4crnJgmN8qlS2h4=; b=jYYyVJA9dMpd0NoCVBxFuCNahSfAWMMiENWyIN4aASn3+k/SEBSt0na6c65uGIk2hj q+TdTEgOHRMjLVcoM5I9U33MkgYI2GRyVEDTMtbGM234S9kN81y9gvKQv38UZz40kxmm /jPfckkbkUG83bw1uWZs88xTWSwlun4MH9SYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=xsMCEhXrmo/7Cp9KyRneB3S8ps08Mniv237GijckfKkQ3OF6Pb7IhRk//Yq+gRSm+W g7IShdw+ev11Lwu97BrqQUr70AxXBu2bGwPm2y1qgvQpPyNKrIkoSJuW+DPi3dEqhD4f RHtbnlrQ2DiPNSQEc9NM/PwJ6nOXUNTQ7mLSI= Received: by 10.43.52.69 with SMTP id vl5mr2560798icb.346.1300946359475; Wed, 23 Mar 2011 22:59:19 -0700 (PDT) Received: from disbatch.dataix.local (adsl-99-181-148-152.dsl.klmzmi.sbcglobal.net [99.181.148.152]) by mx.google.com with ESMTPS id i20sm5583304iby.48.2011.03.23.22.59.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2011 22:59:17 -0700 (PDT) Sender: "J. Hellenthal" Date: Thu, 24 Mar 2011 01:59:14 -0400 From: "J. Hellenthal" To: Jeremy Chadwick In-Reply-To: <20110323232112.GA92114@icarus.home.lan> Message-ID: References: <4D8A61FC.3050303@m5p.com> <4D8A7305.5010805@m5p.com> <20110323225221.GA91414@icarus.home.lan> <4D8A7D97.40406@m5p.com> <20110323232112.GA92114@icarus.home.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, George Mitchell Subject: Re: Firefox startup impacted by distributed.net client X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 05:59:20 -0000 On Wed, 23 Mar 2011 19:21, freebsd@ wrote: > On Wed, Mar 23, 2011 at 07:09:11PM -0400, George Mitchell wrote: >> On 03/23/11 18:52, Jeremy Chadwick wrote: >>> On Wed, Mar 23, 2011 at 06:24:05PM -0400, George Mitchell wrote: >>>> On 03/23/11 17:57, Matthias Gamsjager wrote: >>>>> Have you tried 8 stable? >>>> >>>> The box I tried SCHED_4BSD on was running 8.2_PRERELEASE, which still >>>> had the problem described. Has the scheduler changed significantly >>>> between 8.2_PRERELEASE and stable? -- George Mitchell >>>> >>>>> On 23 Mar 2011 22:12, "George Mitchell" wrote: >>>>>> Original message, from ten months ago: >>>>>> >>>>>> http://lists.freebsd.org/pipermail/freebsd-hackers/2010-May/031915.html >>>>>> >>>>>> Briefly, running the distributed.net client on my FreeBSD 8.0 box >>>>>> made Firefox take forever to start up (90 seconds vs. 2 seconds). >>>>>> The distributed.net client is essentially 100% CPU bound, with >>>>>> occasional file I/O and even more occasional socket I/O, running >>>>>> at nice 20. The problem has persisted since then. >>>>>> >>>>>> So I finally compiled up a kernel using SCHED_4BSD instead of >>>>>> SCHED_ULE. Problem fixed. >>>>>> >>>>>> It still doesn't give me a warm, fuzzy feeling about FreeBSD 8.0, >>>>>> since I still have the awful NFS client performance problem (though >>>>>> not as bad as before the Rick Macklem patch). -- George Mitchell >>> >>> No, it hasn't. >>> >>> You didn't provide any hardware details of your system in the link you >>> referenced (post to -hackers). It matters. dmesg output (regardless of >>> what scheduler you're using in the kernel) would be useful. >> >> Copyright (c) 1992-2011 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.2-PRERELEASE #0: Mon Mar 21 16:03:28 EDT 2011 >> george@scollay.m5p.com:/usr/obj/usr/src/sys/SCOLLAY amd64 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: AMD Sempron(tm) 140 Processor (2712.36-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x100f62 Family = 10 Model = 6 >> Stepping = 2 >> >> Features=0x78bfbff >> Features2=0x802009 >> AMD Features=0xee500800 >> AMD Features2=0x37fd >> TSC: P-state invariant >> real memory = 2147483648 (2048 MB) >> avail memory = 1792958464 (1709 MB) >> ACPI APIC Table: <012810 APIC1758> >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> acpi0: <012810 RSDT1758> on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: reservation of 0, a0000 (3) failed >> acpi0: reservation of 100000, 6ff00000 (3) failed >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 >> cpu0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: at device 0.0 (no driver attached) >> isab0: port 0x900-0x9ff at device 1.0 on pci0 >> isa0: on isab0 >> pci0: at device 1.1 (no driver attached) >> pci0: at device 1.2 (no driver attached) >> ohci0: mem >> 0xdfffb000-0xdfffbfff irq 21 at device 2.0 on pci0 >> ohci0: [ITHREAD] >> usbus0: on ohci0 >> ehci0: mem >> 0xdfffac00-0xdfffacff irq 22 at device 2.1 on pci0 >> ehci0: [ITHREAD] >> usbus1: EHCI version 1.0 >> usbus1: on ehci0 >> pcib1: at device 4.0 on pci0 >> pci1: on pcib1 >> hdac0: mem >> 0xdfff4000-0xdfff7fff irq 23 at device 5.0 on pci0 >> hdac0: HDA Driver Revision: 20100226_0142 >> hdac0: [ITHREAD] >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 6.0 on >> pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> nfe0: port 0xe480-0xe487 >> mem 0xdfff9000-0xdfff9fff irq 20 at device 7.0 on pci0 >> miibus0: on nfe0 >> rgephy0: PHY 3 on miibus0 >> rgephy0: 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, >> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, >> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, >> 1000baseT-FDX-flow-master, auto, auto-flow >> nfe0: Ethernet address: 48:5b:39:07:a8:78 >> nfe0: [FILTER] >> nfe0: [FILTER] >> nfe0: [FILTER] >> nfe0: [FILTER] >> nfe0: [FILTER] >> nfe0: [FILTER] >> nfe0: [FILTER] >> nfe0: [FILTER] >> atapci1: port >> 0xe400-0xe407,0xe080-0xe083,0xe000-0xe007,0xdc00-0xdc03,0xd880-0xd88f >> mem 0xdfff8000-0xdfff8fff irq 21 at device 8.0 on pci0 >> atapci1: [ITHREAD] >> ata2: on atapci1 >> ata2: [ITHREAD] >> ata3: on atapci1 >> ata3: [ITHREAD] >> atapci2: port >> 0xd800-0xd807,0xd480-0xd483,0xd400-0xd407,0xd080-0xd083,0xd000-0xd00f >> mem 0xdffef000-0xdffeffff irq 22 at device 8.1 on pci0 >> atapci2: [ITHREAD] >> ata4: on atapci2 >> ata4: [ITHREAD] >> ata5: on atapci2 >> ata5: [ITHREAD] >> pcib2: at device 9.0 on pci0 >> pci2: on pcib2 >> pcib3: at device 11.0 on pci0 >> pci3: on pcib3 >> pcib4: at device 12.0 on pci0 >> pci4: on pcib4 >> vgapci0: mem >> 0xde000000-0xdeffffff,0xc0000000-0xcfffffff,0xdd000000-0xddffffff >> irq 23 at device 13.0 on pci0 >> acpi_button0: on acpi0 >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> ppc0: port 0x378-0x37f irq 7 on acpi0 >> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >> ppc0: [ITHREAD] >> ppbus0: on ppc0 >> ppi0: on ppbus0 >> plip0: on ppbus0 >> plip0: [ITHREAD] >> lpt0: on ppbus0 >> lpt0: [ITHREAD] >> lpt0: Interrupt-driven port >> acpi_hpet0: iomem 0xfed00000-0xfed00fff >> on acpi0 >> Timecounter "HPET" frequency 25000000 Hz quality 900 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: [ITHREAD] >> psm0: model IntelliMouse, device ID 3 >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart0: [FILTER] >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> hwpstate0: on cpu0 >> Timecounter "TSC" frequency 2712355748 Hz quality 800 >> Timecounters tick every 1.000 msec >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 480Mbps High Speed USB v2.0 >> ad0: 38172MB at ata0-master UDMA133 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ad1: 152627MB at ata0-slave UDMA100 >> ad4: 476940MB at ata2-master UDMA100 >> SATA 1.5Gb/s >> acd0: DVDR at ata5-master UDMA100 >> SATA 1.5Gb/s >> hdac0: HDA Codec #0: Realtek ALC662 >> pcm0: at cad 0 nid 1 on hdac0 >> pcm1: at cad 0 nid 1 on hdac0 >> pcm2: at cad 0 nid 1 on hdac0 >> uhub0: 10 ports with 10 removable, self powered >> GEOM: ad1s1: geometry does not match label (255h,63s != 16h,63s). >> GEOM: ad1s2: geometry does not match label (255h,63s != 16h,63s). >> Root mount waiting for: usbus1 >> Root mount waiting for: usbus1 >> Root mount waiting for: usbus1 >> acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 sks=0x40 >> 0x00 0x01 >> (probe0:ata5:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 >> (probe0:ata5:0:0:0): CAM status: SCSI Status Error >> (probe0:ata5:0:0:0): SCSI status: Check Condition >> (probe0:ata5:0:0:0): SCSI sense: NOT READY asc:3a,1 (Medium not >> present - tray closed) >> uhub1: 10 ports with 10 removable, self powered >> cd0 at ata5 bus 0 scbus2 target 0 lun 0 >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 100.000MB/s transfers >> cd0: Attempt to query device size failed: NOT READY, Medium not >> present - tray closed >> Trying to mount root from ufs:/dev/ad4s1a >> vboxnet0: Ethernet address: 0a:00:27:00:00:00 > > You have a single-core (single processor) system. There's no SMP in use > either (understandable). As I mentioned, there's been discussions on > lists of sub-par performance of ULE on single-core systems. > > As such, I probably wouldn't bother trying SCHED_ULE on this system. > Sticking with SCHED_4BSD is fine in your case. If anyone in the future > brings up the possibility of SCHED_4BSD being removed from the kernel > base, you should scream quite loudly. :-) > >>> As for the next paragraph of your linked post (memory usage and >>> firefox-bin): >>> >>> I can't explain what "ucond" represents in top. That is to say: I know >>> what the STATE field is about, but I can't tell you code-wise what >>> "ucond" represents functionally; my guess is some condition relating to >>> a kernel mutex (thread lock). The relevant code bits in >>> src/sys/kern/kern_umtx.c are over my head. I'm sure a kernel hacker can >>> explain this, but it probably isn't relevant to your problem. >>> >> >> I strongly suspect it was to do with database locking of my >> $HOME/.mozilla/firefox/.../places.sqlite file. -- George Mitchell > > That's a bit of a stretch. truss or ktrace would help here, but it > would require someone to dedicate a bit of time to debug this problem > for you (firefox is a humongous beast; ktrace/truss output from this > program would be gigantic). I'd probably split these two problems > (unfriendly CPU time slicing vs. memory and firefox-bin) up into > separate discussions (or even separate PRs). > > Adding a tidbit of information to this that might or might not make a bit of difference to you. Link [1] that has some scheduling changes that were done in HEAD/-CURRENT that were not merged to -STABLE might be able to help you out some \o/. Also, I found in the past adjusting idprio(1) of processes proves to work out quite well for processes you want to just run in the background and not interrupt your day to day momentary work and especially for dnetc works out quite well. Link [2] I have extracted directly from the email out of convenience and applied and compiled directly into my running test kernels already and has no side effects so far with the 2-3 days its been running. 1. http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022270.html 2. http://patches.jhell.googlecode.com/hg/sched-priority.patch -- Regards, J. Hellenthal (0x89D8547E) JJH48-ARIN