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]
Message-Id: <1221566730.6943.16.camel@lappy.programming.kicks-ass.net>
Date:	Tue, 16 Sep 2008 14:05:30 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	arun@...ux.vnet.ibm.com
Cc:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	ego@...ibm.com, tglx@...utronix.de, mingo@...e.hu,
	andi@...stfloor.org, venkatesh.pallipadi@...el.com,
	vatsa@...ux.vnet.ibm.com
Subject: Re: [RFC PATCH 0/1]: timers: Timer Migration

On Tue, 2008-09-16 at 14:42 +0530, Arun R Bharadwaj wrote:
> Hi,

80 char lines please.

> An idle cpu on which device drivers have initialized timers, has to be
> frequently woken up to service the timers. So, consolidation of timers
> onto a fewer number of cpus is important. Migration of
> timers from idle cpus onto lesser idle cpus is necessary. Currently,
> timers are migrated during the cpu offline operation. However
> cpu-hotplug for the sake of idle system power management is too
> heavy. So, this patch implements a lightweight timer migration
> framework.
> 
> Also, in a multi-core, multi-package system, it is always desirable to
> have all the timers firing on the cpus present in the same package.
> This would enable us to place the idle package in deep sleep
> state. So, migration of timers is required for this.
> 
> A per_cpu sysfs hook is created
> at /sys/devices/system/cpu/cpuX/timer_migration. By echo-ing 1 to
> cpuX/timer_migration, all regular and hrtimers from cpuX are migrated
> to cpu0. The fact that all
> timers are migrated from cpuX to cpu0 is demonstrated by making a note
> of /proc/interrupts.

This seems like an exceedingly dumb idea - cpu 0 might be a long long
way from x and by pushing all timers to cpu0 you might actually overload
cpu 0.

Initially you talked about packages an moving timers to busy cpus -
which is something else altogether.

> $:echo 1 > /sys/devices/system/cpu/cpu3/timer_migration
> $:cat /proc/interrupts > file1; sleep 30 ; cat /proc/interrupts >
> file2
> $:diff file1 file2 | grep LOC
> < LOC:       5276       2100       2676       1647       2415
> 1803       2275       2977   Local timer interrupts
> > LOC:       6991       2195       2774       1647       2562
> 1900       2497       3075   Local timer interrupts
> 
> As we can observe, first we are enabling timer migration in cpu3. As a
> result, the number of local timer interrupts on cpu3 over the next 30
> seconds are zero. cpu3  has been totally rid of all regular
> and hrtimers.
> 
> Please refer to the following paper for details:
> 
> http://ols.fedoraproject.org/OLS/Reprints-2008/srinivasan1-reprint.pdf

If there's anything worth reading in there it should have been mentioned
in this email and preferably in some comment in the code and Kconfig
help as well.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ