linux-kernel - [v6 PATCH 0/4] timers: Framework for migration of timers

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-next>] [day] [month] [year] [list]

Date:	Thu, 16 Apr 2009 12:11:36 +0530
From:	Arun R Bharadwaj <arun@...ux.vnet.ibm.com>
To:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org
Cc:	a.p.zijlstra@...llo.nl, ego@...ibm.com, tglx@...utronix.de,
	mingo@...e.hu, andi@...stfloor.org, venkatesh.pallipadi@...el.com,
	vatsa@...ux.vnet.ibm.com, arjan@...radead.org,
	svaidy@...ux.vnet.ibm.com, arun@...ux.vnet.ibm.com,
	Richard Henderson <rth@...ddle.net>,
	Chris Zankel <chris@...kel.net>,
	Mikael Starvik <starvik@...s.com>,
	Jesper Nilsson <jesper.nilsson@...s.com>,
	Tony Luck <tony.luck@...el.com>,
	Kyle McMartin <kyle@...artin.ca>
Subject: [v6 PATCH 0/4] timers: Framework for migration of timers

Ingo, Thomas, all,

In an SMP system, tasks are scheduled on different CPUs by the
scheduler, interrupts are managed by irqbalancer daemon, but timers
are still stuck to the CPUs that they have been initialised.  Timers
queued by tasks gets re-queued on the CPU where the task gets to run
next, but timers from IRQ context like the ones in device drivers are
still stuck on the CPU they were initialised.  This framework will
help move all 'movable timers' using a sysctl interface.

Please consider for inclusion into -tip

Testing Carried Out:

* Kernbench on a 2-package, quad-core machine results are as follows:

-----------------------------------------------------------------------
| No. of Threads  |	 Time(s) - Without   |	   Time(s) - With the |
|		  |       patches applied    |	     patches applied  |
-----------------------------------------------------------------------
|	2	  |	      106.9	     |		106.3	      |
|	4	  |	       54.7	     |		 54.4	      |
|	8	  |	       31.5	     |		 31.1	      |
|      16	  |	       28.0	     |		 27.5	      |
|      32	  |	       28.1	     |		 28.9	      |
-----------------------------------------------------------------------

* I have cross-compiled my patches against alpha architecture in order
to test if my patches have any issues for architectures without
clockevents support.

The patches cross-compile without any issues for alpha architecture,
but I need help to test if there is any performance regression.
So I'm Cc-ing the maintainers of architectures without clockevents support.

The following patches are included:
PATCH 1/4 - framework to identify pinned timers.
PATCH 2/4 - identifying the existing pinned hrtimers.
PATCH 3/4 - /proc/sys sysctl hook to enable timer migration.
PATCH 4/4 - logic to enable timer migration.

The patchset is based on the latest tip/master.

Timer migration is enabled by default.
It can be turned off when CONFIG_SCHED_DEBUG=y by

echo 0 > /proc/sys/kernel/timer_migration

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