linux-kernel - Re: A few questions and issues with dynticks, NOHZ and powertop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 4 Apr 2010 11:17:37 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Dominik Brodowski <linux@...inikbrodowski.net>
cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Dmitry Torokhov <dtor@...l.ru>
Subject: Re: A few questions and issues with dynticks, NOHZ and powertop

On Sun, 4 Apr 2010, Dominik Brodowski wrote:

> Booting a SMP-capable kernel with "nosmp", or manually offlining one CPU
> (or -- though I haven't tested it -- booting a SMP-capable kernel on a
> system with merely one CPU) means that in up to about half of the calls to
> tick_nohz_stop_sched_tick() are aborted due to rcu_needs_cpu(). This is
> quite strange to me: AFAIK, RCU is an excellent tool for SMP, but not really
> needed for UP?

I can't answer the real question here, not knowing enough about the RCU
implementation.  However, your impression is wrong: RCU very definitely
_is_ useful and needed on UP systems.  It coordinates among processes
(and interrupt handlers) as well as among processors.


> 3) USB: built-in UHCI and a built-in 0a5c:2101 Broadcom Corp. A-Link
> BlueUsbA2 Bluetooth module; built-in EHCI and a built-in 0ac8:c302 Z-Star
> Microelectronics Corp. Vega USB 2.0 Camera.
> 
> usbcore.autosuspend is enabled (= 2), of course.
> 
> Recent USB suspend statistics
> Active  Device name
> 100.0%	USB device  7-1 : BCM92045NMD (Broadcom Corp)
> 100.0%	USB device  1-2 : Vega USB 2.0 Camera. (Vimicro Corp.)
> 100.0%	USB device usb7 : UHCI Host Controller (Linux 2.6.34-rc3 uhci_hcd)
> 100.0%	USB device usb1 : EHCI Host Controller (Linux 2.6.34-rc3 ehci_hcd)
> 
> Booting into /bin/bash on a SMP kernel booted with "nosmp" leads to ~ 10
> wakeups per second; disabling the cursor helps halfway (~ 5 wakeups); and
> manually unbinding the USB host drivers from the USB host devices finally
> lead to ~ 1.1 wakeups per second. What's keeping USB from suspending these
> unused devices here?

Either the drivers don't support autosuspend or the devices aren't
enabled for autosuspend.  By default, autosuspend is disabled for
(almost) all non-hub devices.  You or your distribution must enable
it manually by doing:

	echo auto >/sys/bus/usb/devices/.../power/level

If the driver doesn't support autosuspend then enabling it won't be
enough; you'll also have to unbind the driver from the device.  The
easiest way to do this is to unconfigure the device:

	echo 0 >/sys/bus/usb/devices/.../bConfigurationValue

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/