From owner-freebsd-current@FreeBSD.ORG Wed Oct 27 08:14:27 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0447E1065675; Wed, 27 Oct 2010 08:14:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 58C698FC15; Wed, 27 Oct 2010 08:14:25 +0000 (UTC) Received: by bwz3 with SMTP id 3so283940bwz.13 for ; Wed, 27 Oct 2010 01:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=GQZ/4iSm5oNKXM5G8WowQrlO3qUqjm6ZVWGBj6LUyQc=; b=c0loJM1+rMJ5YVog/ziD+nEM5+SiiK9qmIpoVjxad5dF2HrP+t6goD5UEal4oKh6ms tHDU57bM93SPkRPYgD7Zwzsh3Dqb4XdxsY0bKQZPbVX/+vCewwwvzOg7b8dNhF62C+5C hku3hlgMa0n506IM2IacVARn31DEU1Wk5fRAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=iY8iq1LildKsVscNUG5/ULApGpqxvn4NkxBV3u5T3AG+rLuocT7zJS71djjg1TBhTz 3aiWm0noo6JYyPYrORVFs8IiL8ZnXNh1XVFzMzYXUV4rb7RX3KwidgGtguyERfDnXCcv Nz59eVxI9NOZL+n+WnOunyEJfP5A1l87nW3Uw= Received: by 10.204.118.209 with SMTP id w17mr6494844bkq.107.1288167265138; Wed, 27 Oct 2010 01:14:25 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([91.198.175.253]) by mx.google.com with ESMTPS id 4sm6731536bki.1.2010.10.27.01.14.20 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Oct 2010 01:14:21 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CC7DF5A.6070904@FreeBSD.org> Date: Wed, 27 Oct 2010 11:14:18 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: Nate Lawson References: <201010261904.o9QJ4iwq089834@sana.init-main.com> <4CC732C7.50409@FreeBSD.org> <4CC759D5.2020207@root.org> In-Reply-To: <4CC759D5.2020207@root.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org, current@freebsd.org Subject: Re: Event based scheduling and USB. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 08:14:27 -0000 Nate Lawson wrote: > On 10/26/2010 12:57 PM, Alexander Motin wrote: >> Takanori Watanabe wrote: >>> I updated my FreeBSD tree on laptop, to the current >>> as of 18 Oct.2010, it works fine with CPU C3 state enabled, >>> >>> I think this is your achievement of event time scheduler, >>> thanks! > > Ah, so mav@ implemented a tickless-scheduler? That is nice. Not exactly. I've only made system to delay empty ticks when idle and execute them later on wakeup in a batch. Scheduler work is still wanted. >>> But when USB driver is enabled, the load average is considerablly >>> high (0.6 to 1.0) if sysctl oid kern.eventtimer.periodic is set to 0. >>> Then kern.eventtimer.periodic is set to 1, the load average goes >>> to 0 quickly as before, but almost never transit to C3. >>> >>> Is this behavior expected, or something wrong? > > The USB controller often keeps the bus mastering bit set. This keeps the > system out of C3. The way to fix this is to implement global suspend. > Put a device in suspend mode and then turn off power to the USB port it > is on. Then the USB controller will stop polling the bus. As I understand, if respective USB port is not used, USB stack should put it into power_save mode not poll so often to deny entering C3 state. >>> I noticed one of usb host controller device shares HPET irq. >>> When I implement interrupt filter in uhci driver, the load average >>> goes to 0 as before. >>> >>> >>> ==== >>> % vmstat -i >>> interrupt total rate >>> irq1: atkbd0 398 2 >>> irq9: acpi0 408 2 >>> irq12: psm0 3 0 >>> irq19: ehci1 37 0 >>> irq20: hpet0 uhci0 35970 230 >>> irq22: ehci0 2 0 >>> irq256: em0 4 0 >>> irq257: ahci0 1692 10 >>> Total 38514 246 >>> === >> I haven't noticed that issue and it is surely not expected for me. I >> will try to reproduce it. >> >> Most likely you should be able to avoid interrupt sharing using some >> additional HPET options, described at hpet(4). > > This seems silly. The whole point of APIC is to avoid clustering on a > single interrupt but the BIOS put the timer on the USB controller irq? HPET timer is not a regular ISA or PCI device. It allows several different interrupt configurations. In most cases I remember, BIOS setups interrupts 0 and 8, like for legacy_route mode. But this mode is not really suitable as default in our case ATM due to conflict with atrtc and attimer drivers. -- Alexander Motin