Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756793Ab2ECO5H (ORCPT ); Thu, 3 May 2012 10:57:07 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:57550 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755113Ab2ECO5F (ORCPT ); Thu, 3 May 2012 10:57:05 -0400 From: Gilad Ben-Yossef To: linux-kernel@vger.kernel.org Cc: Gilad Ben-Yossef , Thomas Gleixner , Tejun Heo , John Stultz , Andrew Morton , KOSAKI Motohiro , Mel Gorman , Mike Frysinger , David Rientjes , Hugh Dickins , Minchan Kim , Konstantin Khlebnikov , Christoph Lameter , Chris Metcalf , Hakan Akkan , Max Krasnyansky , Frederic Weisbecker , linux-mm@kvack.org Subject: [PATCH v1 0/6] reduce workqueue and timer noise Date: Thu, 3 May 2012 17:55:56 +0300 Message-Id: <1336056962-10465-1-git-send-email-gilad@benyossef.com> X-Mailer: git-send-email 1.7.0.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3599 Lines: 87 Timers and work queues both provide a useful way to defer work for a later time or a different context. However, when the timer or work item runs, it interrupts the CPU it is running on. This is good if it is doing useful work, but it turns out this is not always the case. This patch set tries to locate and address code paths where work queues items and timers are scheduled on CPUs where they have no useful work to do and adapet them to be more selective. This includes: - Introducing helper function to schedule work queue items on a subset of CPUs in the system. - Use the helper function to schedule work items to attempt to drain LRUs only on CPUs where there are LRU pages. - Stop running the per cpu work item that does per-cpu pages reclaim and VM statistics on CPUs that did not have any VM activity for the last second (time frame configurable) and re-start it when VM activity is detected. - Fix a bug that prevented the timer code to to not program the underlying HW timer to fire periodically when no future timer event exists for a CPU Changelog: - The vmstat_update patch was changed to use a scapegoat CPU as suggested by Christoph Lameter when the patch was previously discussed in response to Frederic Weisbecker's adaptive tick patch set. Also included is a testing only patch, not intdented for mainline, that turns the clock source watchdog into a config option which I used while testing the timer code fix change. The patch was boot tested on 32bit x86 in 8 way SMP and UP VMs. For you reference, I keep a todo list for these and other noise sources at: https://github.com/gby/linux/wiki The git branched can be fetched from the git repo at git@github.com:gby/linux.git on the reduce_workqueue_and_timers_noise_v1 branch Gilad Ben-Yossef (6): timer: make __next_timer_interrupt explicit about no future event workqueue: introduce schedule_on_each_cpu_mask workqueue: introduce schedule_on_each_cpu_cond mm: make lru_drain selective where it schedules work mm: make vmstat_update periodic run conditional x86: make clocksource watchdog configurable (not for mainline) arch/x86/Kconfig | 9 +++- include/linux/vmstat.h | 2 +- include/linux/workqueue.h | 4 ++ kernel/time/clocksource.c | 2 + kernel/timer.c | 31 ++++++++++----- kernel/workqueue.c | 73 ++++++++++++++++++++++++++++++---- mm/swap.c | 25 +++++++++++- mm/vmstat.c | 95 ++++++++++++++++++++++++++++++++++++++------- 8 files changed, 204 insertions(+), 37 deletions(-) Signed-off-by: Gilad Ben-Yossef CC: Thomas Gleixner CC: Tejun Heo CC: John Stultz CC: Andrew Morton CC: KOSAKI Motohiro CC: Mel Gorman CC: Mike Frysinger CC: David Rientjes CC: Hugh Dickins CC: Minchan Kim CC: Konstantin Khlebnikov CC: Christoph Lameter CC: Chris Metcalf CC: Hakan Akkan CC: Max Krasnyansky CC: Frederic Weisbecker CC: linux-kernel@vger.kernel.org CC: linux-mm@kvack.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/