Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756730Ab2EHPed (ORCPT ); Tue, 8 May 2012 11:34:33 -0400 Received: from smtp110.prem.mail.ac4.yahoo.com ([76.13.13.93]:36367 "HELO smtp110.prem.mail.ac4.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1755664Ab2EHPec (ORCPT ); Tue, 8 May 2012 11:34:32 -0400 X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Po6hDRcVM1lQEUxpX.43dDC5TTKjl7Kdh4qivH6CqWZU1zT WZbSQQa3TKGUCARoUaDAGsFfb7G3kN6HANwvcqP91xfRVeXAwaVdvN7Me1Wn z1Ivb4NUy2a.DodXj2IdTSpDWFFygddVxAFpaGeR4z.67HTxE10owBalyCFB xXWO.v3PtQuUkheNk659mKKVJHlmEgezhpLmlfNjHbneW0IhdrP1wuSgO606 TiHElm561UAkVpC1a5k9vG7ZRxOyrcBHZ7NCeP0WMRRuZYw8TPJI.npWIyDw 7vOwor40uiJPTmQiO_bSLSo8y9iAn6QRJ04DcU1xCQoaO4pgdR8OhIvW1Xxs hB9UL.5UPR1WBlwTq9y9sGiz993xSlO7vPURpHu97t3mSMm8voXNdo6sUKDn Y X-Yahoo-SMTP: _Dag8S.swBC1p4FJKLCXbs8NQzyse1SYSgnAbY0- Date: Tue, 8 May 2012 10:34:25 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@router.home To: Gilad Ben-Yossef cc: KOSAKI Motohiro , linux-kernel@vger.kernel.org, Thomas Gleixner , Tejun Heo , John Stultz , Andrew Morton , KOSAKI Motohiro , Mel Gorman , Mike Frysinger , David Rientjes , Hugh Dickins , Minchan Kim , Konstantin Khlebnikov , Chris Metcalf , Hakan Akkan , Max Krasnyansky , Frederic Weisbecker , linux-mm@kvack.org Subject: Re: [PATCH v1 5/6] mm: make vmstat_update periodic run conditional In-Reply-To: Message-ID: References: <1336056962-10465-1-git-send-email-gilad@benyossef.com> <1336056962-10465-6-git-send-email-gilad@benyossef.com> <4FA823A7.9000801@gmail.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1016 Lines: 26 On Tue, 8 May 2012, Gilad Ben-Yossef wrote: > > But this would still mean that the vmstat update thread would run on an > > arbitrary cpu. If I have a sacrificial lamb processor for OS processing > > then I would expect the vmstat update thread to stick to that processor > > and avoid to run on the other processor that I would like to be as free > > from OS noise as possible. > > > > OK, what about - > > - We pick a scapegoat cpu (the first to come up gets the job). > - We add a knob to let user designate another cpu for the job. > - If scapegoat cpus goes offline, the cpu processing the off lining is > the new scapegoat. > > Does this makes better sense? Sounds good. The first that comes up. If the cpu is isolated then the first non isolated cpu is picked. -- 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/